The Professional Product Owner

Leveraging Scrum as a Competitive Advantage

توضیحات

نظر

امتیاز : 00/10
به دیگران توصیه می‌کنم :
دوباره می‌خوانم :
ایده برجسته :
تاثیر در من :
نکات مثبت :
نکات منفی :

مشخصات

نویسنده :
انتشارات :
صفحه مشخصات :

بخش‌هایی از کتاب

فصل ۱: مدیریت چابک محصول (Agile Product Management)

بخش اول: ذهنیت محصول در مقابل ذهنیت پروژه (Product Mindset vs. Project Mindset)

نویسندگان این کتاب با یک مثال واقعی و تاثیرگذار شروع می‌کنند: داستان نوکیا.

تحلیل انتقادی: چرا موفقیت پروژه‌ها به معنای موفقیت کسب‌وکار نیست؟

ذهنیت پروژه‌محور (Project Mindset) این‌گونه عمل می‌کند:

یک ایده → شروع پروژه
یک Project Manager مهارت‌های مدیریت تسک و افراد دارد، اما لزوماً دانش یا علاقه به دامنه کاری (Domain) ندارد
موفقیت با سه معیار سنجیده می‌شود: Scope (محدوده)، Time (زمان)، Budget (بودجه)

اما نویسندگان سوال کلیدی را مطرح می‌کنند:

“چه می‌شود اگر پروژه‌ای در زمان مقرر، با بودجه تعیین‌شده و در محدوده مشخص‌شده تحویل شود، اما باز هم شکست بخورد؟”

مثال نوکیا: این شرکت سال‌ها رهبر بازار تلفن همراه بود. هر پروژه‌ای را در زمان مقرر تحویل می‌داد. اما در نهایت، مایکروسافت ۷.۲ میلیارد دلار برای نوکیا (با ۱۰۰,۰۰۰ کارمند و زیرساخت‌های عظیم) پرداخت کرد - کمتر از ۸.۶ میلیارد دلاری که برای Skype (با چند صد نفر کارمند) داده بود.

نتیجه‌گیری نویسنده: ذهنیت پروژه‌محور موفقیت را از “درون به بیرون” (Inside-Out) تعریف می‌کند - بر اساس معیارهای داخلی مانند Task Management و پایبندی به برنامه اولیه.

بخش دوم: ذهنیت محصول‌محور (Product Mindset) — رویکرد جایگزین

Product Mindset چیست؟

نویسندگان پیشنهاد می‌کنند که به جای مدیریت پروژه، ایده را به عنوان یک محصول در نظر بگیرید. یعنی:

ایده را به یک تیم توانمند بسپارید و به جای تسک‌های دقیق، اهداف تجاری معنادار تعریف کنید؛ مانند میزان پذیرش کاربر، فروش، و رضایت ذینفعان.

تفاوت بنیادین در جهت‌گیری

ذهنیت پروژه‌محور موفقیت را از درون به بیرون (Inside-Out) می‌سنجد — معیارهایش داخلی هستند: آیا به برنامه اولیه پایبند بودیم؟

ذهنیت محصول‌محور موفقیت را از بیرون به درون (Outside-In) می‌سنجد — معیارهایش خارجی هستند: آیا ارزش واقعی به مشتری رسید؟

مزایای Product Mindset

این رویکرد سه تحول اساسی ایجاد می‌کند:

انتشار مکرر‌تر → بازخورد زودتر از بازار می‌رسد
انتقال هدف به جای تسک → تیم‌ها خلاق‌تر می‌شوند، راه‌حل‌های بهتری ارائه می‌دهند و احساس مسئولیت بیشتری دارند
حذف اتلاف (Waste) → وابستگی کمتر به Task Assignment، گزارش‌دهی و تصمیمات مدیریتی

آسیب‌های Project Mindset

در مقابل، ذهنیت پروژه‌محور به این مشکلات منجر می‌شود:

درگیری کمتر کسب‌وکار در فرآیند توسعه
Handoff‌های بیشتر بین تیم‌ها
مدیریت تسک افراطی
مدیریت افراد به جای مدیریت ارزش

نکته کلیدی نویسنده

جمله‌ای که بارها در این کتاب تکرار می‌شود:

“اگر شما یا سازمانتان بیشتر به پروژه فکر کنید تا به محصول و ارزش، جریان موفقیت می‌تواند بسیار سریع جهت عوض کند.”

سوالی که Product Mindset در ذهن تیم ایجاد می‌کند این است:

“اولین چیزی که بیشترین تأثیر را بر اهداف ما دارد، چیست و چه زمانی می‌توانیم آن را منتشر کنیم؟”

این سوال، پل ارتباطی بین تیم توسعه و کسب‌وکار است.

بخش سوم: خلأ مدیریت محصول (Product Management Vacuum) و سه V

لایه‌های برنامه‌ریزی در یک سازمان

نویسندگان توضیح می‌دهند که در هر سازمان محصول‌محور، سه لایه برنامه‌ریزی وجود دارد:

لایه خارجی: Vision و Strategy شرکت، که توسط مدیر ارشد یا CEO تعریف می‌شود
لایه داخلی: برنامه Sprint و برنامه روزانه، که متعلق به تیم توسعه است
لایه میانی: یک خلأ (Vacuum) که اگر پر نشود، بحران‌ساز می‌شود

این فاصله میانی، Product Management Vacuum نام دارد و انگیزه اصلی نوشتن این کتاب است.

خلأ وقتی پر نشود چه اتفاقی می‌افتد؟

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

گروه‌های فناوری از کسب‌وکار فاصله بیشتری می‌گیرند
وابستگی به Project Management و Task Management افزایش می‌یابد
سلسله‌مراتب و Handoff‌های بیشتری شکل می‌گیرند
تغییر مسیر در برابر تحولات بازار دشوارتر می‌شود
اتلاف (Waste) و بازنویسی (Rework) بیشتری رخ می‌دهد
ارزش کمتری به مشتری تحویل داده می‌شود

راه‌حل: سه V

نویسندگان برای پر کردن این خلأ به درستی، از سه V استفاده می‌کنند:

Vision → Value → Validation

V اول: Vision (چشم‌انداز)

Vision creates Transparency — چشم‌انداز، شفافیت می‌آفریند.

Product Owner موفق، دقیقاً مانند یک فرمانده نظامی عمل می‌کند که intent خود را به وضوح برای زیردستانش تعریف می‌کند؛ به گونه‌ای که حتی بدون دستور مستقیم هم بتوانند در راستای هدف حرکت کنند.

نکته تحقیقاتی مهم: طبق پژوهش Richard Hackman، سی درصد از موفقیت یک تیم به نحوه آغاز به کار آن بستگی دارد. یک Vision قوی و به‌خوبی منتقل‌شده، پایه این موفقیت است.

نویسنده هشدار می‌دهد: وقتی از انسان‌ها به عنوان “resource” یاد می‌کنیم و فقط فهرست نیازمندی‌ها به دستشان می‌دهیم، آن‌ها فاقد Situational Awareness هستند؛ دقیقاً آنچه که خواسته شده را پیاده می‌کنند، اما اغلب از هدف واقعی فاصله می‌گیرند.

V دوم: Value (ارزش)

Defining value provides you with something to Inspect — تعریف ارزش، چیزی برای بازبینی فراهم می‌کند.

نویسنده با یک استعاره زیبا توضیح می‌دهد:

Vision مانند یک نخ بلند است. Value مانند مرواریدهایی است که یکی‌یکی به آن می‌آویزید. بدون مروارید، نخ هیچ ارزشی ندارد.

قانون کلیدی: همیشه ارزشمندترین آیتم را اول تحویل دهید. سوالی که در این مرحله باید پرسید:

“اگر فقط یک چیز می‌توانستید داشته باشید، چه بود؟”

اما تنها شناسایی ارزش کافی نیست؛ باید ارزش را کمّی کنید. آیا فرآیند با کلیک کمتری انجام می‌شود؟ چقدر کمتر؟ رفتار کاربر چگونه تغییر می‌کند؟ اگر نتوانید موفقیت را اندازه بگیرید، احتمال زیادی وجود دارد که در مسیر اشتباه باشید.

V سوم: Validation (اعتبارسنجی)

Validation causes Adaptation — اعتبارسنجی، انطباق ایجاد می‌کند.

نویسنده یک واقعیت تلخ را بیان می‌کند:

اکثر فرضیه‌های تجاری اشتباه هستند. روی کاغذ خوب به نظر می‌رسند، اما در دنیای واقعی دوام نمی‌آورند.

در Scrum، Sprint Review فرصتی برای Validation است، اما Validation واقعی تنها زمانی اتفاق می‌افتد که محصول در Production باشد و توسط کاربر واقعی استفاده شود. دو حلقه بازخورد در Scrum وجود دارد:

Process Validation: بررسی اینکه تیم چگونه کار می‌کند
Product Validation: بررسی اینکه تیم چه چیزی می‌سازد

در بحث مدیریت محصول و سه V، فقط Product Validation مدنظر است.

بخش چهارم: Product Owner و انواع آن

چرا نقش مهم‌تر از عنوان است؟

نویسندگان تأکید می‌کنند که داشتن Product Owner در Scrum کافی نیست؛ نوع و شخصیت آن فرد تعیین می‌کند که چقدر از پتانسیل Scrum محقق می‌شود. آن‌ها پنج نوع Product Owner را بر اساس میزان تأثیرگذاری مشخص کرده‌اند:

۱. Scribe (منشی)

این فرد معمولاً از سمت تیم فناوری می‌آید و وظیفه‌اش نوشتن آنچه در جلسات گفته می‌شود است. نه اختیار تصمیم‌گیری دارد و نه توانایی اولویت‌بندی مستقل.

نویسنده به صراحت می‌گوید: این نوع Product Owner بیشتر شبیه یک منشی جلسه است تا یک رهبر محصول. نتیجه مستقیم: تأخیر در تمام سطوح.

۲. Proxy (واسط)

این فرد هم معمولاً از سمت فناوری می‌آید و خود را نماینده کسب‌وکار معرفی می‌کند؛ اغلب عنوان Business Analyst یا System Analyst دارد. مشکل اصلی این است که یک لایه غیرضروری بین تیم توسعه و تصمیم‌گیران واقعی ایجاد می‌کند.

پاسخ کلیشه‌ای Proxy در برابر هر سوال: “بذار برم بپرسم.” این جمله به تنهایی کافی است تا بدانید با یک Proxy طرفید. علاوه بر این، Proxy ممکن است از نقش خود محافظت کند و ارتباط مستقیم تیم با کسب‌وکار را عمداً قطع کند.

۳. Business Representative (نماینده کسب‌وکار)

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

این فرد همان کسی است که business case اولیه را نوشته و بودجه را تامین کرده است. بنابراین اعتماد و اختیار لازم برای تصمیم‌گیری فوری در مورد محصول و بودجه را دارد. نتیجه مستقیم این است که تیم توسعه کمتر متوقف می‌شود و جریان کار بهتری شکل می‌گیرد.

۵. Entrepreneur (کارآفرین) — ایده‌آل‌ترین نوع

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

نویسنده صادقانه اعتراف می‌کند که این سطح از Ownership در سازمان‌های بزرگ نادر است، اما mindset کارآفرینانه چیزی است که هر Product Owner باید داشته باشد؛ به گونه‌ای که انگار ROI از جیب خودش می‌رود.

خط فاصل بین دو دسته

نویسندگان یک تمایز بنیادین ترسیم می‌کنند:

دسته	انواع	رابطه با محصول
Receiving (دریافت‌کننده)	Scribe، Proxy	به آن‌ها گفته می‌شود چه بسازند
Initiating (آغازگر)	Business Rep، Sponsor، Entrepreneur	آن‌ها تشخیص می‌دهند چه بسازند

تفاوت کلیدی این دو دسته در Customer Empathy است. افراد دسته دوم به دلیل درک عمیق‌تر کسب‌وکار و ارتباط دوطرفه با مشتری، می‌توانند نیازمندی‌های درست را شروع کنند، نه صرفاً دریافت کنند.

هشدار مهم نویسنده

یک تله ظریف وجود دارد: هرچه Product Owner به سمت Sponsor پیش می‌رود، ممکن است از تیم توسعه فاصله بگیرد. حفظ ارتباط با تیم و Vision محصول در این شرایط، نشانه یک Product Owner کارآفرین واقعی است.

بخش پنجم: تعریف محصول، قانون Conway و قانون بابانوئل

محصول چیست؟

نویسندگان تعریفی کلاسیک از فیلیپ کاتلر ارائه می‌دهند:

محصول، هر چیزی است که بتوان آن را به بازار عرضه کرد و نیاز یا خواسته‌ای را برآورده کند.

اما این تعریف به تنهایی کافی نیست. نویسندگان سه اصل بنیادین اضافه می‌کنند:

همیشه یک محصول وجود دارد — شاید آشکار نباشد، اما هست و باید شناسایی شود
هر محصول یک مشتری دارد — یا Consumer (کسی که از محصول ارزش می‌گیرد)، یا Buyer (کسی که پول می‌دهد)، یا هر دو
هر محصول یک تولیدکننده دارد که از آن سود می‌برد — از طریق افزایش درآمد، کاهش هزینه، یا منفعت اجتماعی

دام رایج: Component را با Product اشتباه گرفتن

نویسنده یک مثال واقعی و گویا از دوره‌های آموزشی‌اش می‌آورد:

یکی از شرکت‌کنندگان در دوره آموزشی خود را این‌گونه معرفی کرد: “من Product Owner برای Testing هستم.” نویسنده می‌گوید: معمولاً کلمات به سرعت از دهانم خارج می‌شوند، اما این بار واقعاً لحظه‌ای بی‌کلام ماندم.

این اشتباه یکی از شایع‌ترین آسیب‌ها در سازمان‌هاست و قانون Conway آن را توضیح می‌دهد:

“سازمان‌هایی که سیستم طراحی می‌کنند، محکوم به تولید طراحی‌هایی هستند که کپی ساختار ارتباطی خود سازمان هستند.”

به عبارت ساده‌تر: اگر سازمان شما به بخش‌های جداگانه تقسیم شده باشد، محصول نرم‌افزاری‌تان هم همان ساختار را خواهد داشت — نه آنچه مشتری نیاز دارد. به همین دلیل Scrum نقش را Product Owner می‌نامد، نه System Owner یا Component Owner.

مثال خودرو: از کجا شروع کنیم؟

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

اگر والدین ماشین می‌خرند، هم Buyer هستند هم Consumer. اما اگر برای فرزند می‌خرند، والد Buyer است و فرزند Consumer. بنابراین شرکت خودروساز باید برای هر دو طراحی کند: کیسه هوا و رتبه ایمنی برای والد، رنگ‌های شاد و سیستم چندرسانه‌ای برای نوجوان.

محصول Viable چیست؟

شناسایی محصول کافی نیست؛ محصول باید Viable هم باشد — یعنی سود اعلام‌شده برای تولیدکننده واقعاً محقق شود.

نویسنده یک مثال چالش‌برانگیز می‌زند: آیا یک گروه QA که تست‌های Automated می‌نویسد، محصول دارد؟ بله. اما آیا ROI آن واقعی است؟ احتمالاً خیر — چون سایر تیم‌های توسعه محیط تستی را که خودشان نساخته‌اند نمی‌پذیرند و نگهداری آن هم با چالش روبروست.

قانون بابانوئل (Santa Claus Rule)

نویسندگان یک قانون شیرین اما عمیق مطرح می‌کنند:

بابانوئل هر چقدر هم که مشغول باشد، هرگز بابانوئل دیگری استخدام نمی‌کند. راه‌حل او: جن‌ها (Elves).

معنی این قانون برای Product Owner این است: یک Product Owner باید بتواند برای تعداد زیادی از تیم‌های توسعه یک محصول کار کند — درست مانند یک CEO که یک شرکت را هدایت می‌کند، چه ۱۰۰ نفر کارمند داشته باشد چه ۱۰۰،۰۰۰ نفر.

هرچه محصول رشد می‌کند، Product Owner باید از تاکتیک‌های روزانه فاصله بگیرد و روی استراتژی و جهت‌دهی متمرکز شود. می‌تواند مسئولیت‌های تاکتیکی را به تیم‌ها، Stakeholderها و دستیاران واگذار کند — اما پاسخگویی همچنان با اوست.

وقتی محصول واقعاً بزرگ شد: Value Domains

اگر حتی یک Product Owner با تعداد زیادی از تیم‌ها کار کردن هم ممکن نبود، نویسندگان راه‌حل زیر را پیشنهاد می‌دهند:

محصول را به Value Domains (حوزه‌های ارزش مستقل با تمرکز بر مشتری) تقسیم کنید و برای هر Domain یک Product Owner تعیین کنید — نه بر اساس ساختار فنی یا Component. این ساختار به طور طبیعی جایگزین Steering Committee، PMO و بوروکراسی حاکمیتی می‌شود.

نویسنده از یک تجربه واقعی می‌گوید: یک مشتری چند Product Owner داشت که به صورت Round-Robin از لیست‌هایشان برای Sprint انتخاب می‌کردند. اگرچه این روش در نگاه اول منصفانه به نظر می‌رسید، اما هیچ‌کس مطمئن نبود آیا تیم‌ها واقعاً روی ارزشمندترین Feature‌ها کار می‌کنند. آن کسی که در نهایت تصمیم می‌گیرد، Product Owner واقعی است.

فصل ۲: Vision (چشم‌انداز) — بخش اول

Vision چیست؟ تعریف دقیق

نویسندگان با یک تمایز مهم شروع می‌کنند که اکثر تیم‌ها از آن غافل هستند:

Vision نه یک Mission Statement است، نه یک Strategic Plan. Vision، مقصد واقعی است؛ توصیفی زنده از اینکه موفقیت چه شکلی دارد.

از تعریف Ari Weinzweig بنیان‌گذار Zingerman’s استفاده می‌شود:

“Vision تصویری از موفقیت در یک نقطه مشخص در آینده است. مانند ستاره قطبی است — همیشه در دیدرس، اما هرگز به آن نمی‌رسید. نقشه راه نیست؛ خود مقصد است.”

یک Vision موثر باید چهار ویژگی داشته باشد:

Inspiring — همه کسانی که قرار است آن را پیاده کنند باید الهام بگیرند
Strategically Sound — شانس واقعی برای تحقق داشته باشد
Documented — نوشته شود تا وجود داشته باشد
Communicated — بارها و بارها منتقل شود

Business Modeling: نقطه شروع Vision

قبل از اینکه Vision بنویسید، باید مدل کسب‌وکار محصولتان را درک کنید. نویسندگان ابزار Business Model Canvas را به عنوان یکی از محبوب‌ترین و کارآمدترین روش‌ها معرفی می‌کنند.

Business Model Canvas از نه بخش تشکیل شده است که به ترتیب زیر باید آن‌ها را با Stakeholderها مرور کنید:

ترتیب	بخش	توضیح
۱	Customer Segments	از اینجا شروع کنید. چه کسانی از محصول ارزش می‌گیرند؟
۲	Value Propositions	نیاز هر Segment چیست و محصول چگونه آن را برآورده می‌کند؟
۳	Channels	چگونه Value Proposition به مشتری می‌رسد؟
۴	Customer Relationships	چطور مشتری را نگه می‌دارید و به بازگشت تشویق می‌کنید؟
۵	Revenue Streams	مشتری چقدر و به چه شکلی پول می‌دهد؟
۶	Key Activities	برای تحقق Value چه کارهایی باید انجام دهید؟
۷	Key Resources	به چه چیزهایی (افراد، تجهیزات، ابزار) نیاز دارید؟
۸	Key Partners	چه شراکت‌هایی بهتر از انجام‌دادن خودتان است؟
۹	Cost Structure	هزینه‌های اصلی برای ساختن این محصول چیست؟

نکته عملی نویسنده: پنج بخش اول مربوط به درآمد هستند و چهار بخش آخر مربوط به هزینه. هدف از Canvas این نیست که بلافاصله یک Vision کامل داشته باشید؛ بلکه داده‌ای فراهم می‌کند که از آن Vision بسازید.

Product Vision: از Canvas به جمله‌ای که الهام می‌دهد

نویسندگان یک مشکل رایج را شفاف می‌کنند: اکثر Vision Statementها پر از کلمات قالبی و بی‌روح هستند — جملاتی که هیچ‌کس نه حسی به آن‌ها دارد، نه آن‌ها را به خاطر می‌سپارد.

یک Vision خوب باید چهار ویژگی داشته باشد که نویسندگان آن را FEPP می‌نامند:

Focused (متمرکز): مشخص کند که چه کسی مشتری هدف است و چه ارزشی برای او ایجاد می‌شود. شما نمی‌توانید همه چیز برای همه کس باشید
Emotional (احساسی): بتواند چیزی را در مخاطب تحریک کند؛ حسی ایجاد کند
Practical (عملی): مشتری بتواند تصور کند که با محصول چه کاری انجام می‌دهد
Pervasive (فراگیر): همه جا حضور داشته باشد و مدام تکرار شود

تکنیک Product Box

برای ساختن Vision متمرکز، نویسندگان تکنیک Innovation Games Product Box را معرفی می‌کنند:

یک جعبه خالی به Stakeholderها بدهید و از آن‌ها بخواهید جعبه محصول نرم‌افزاری‌شان را طراحی کنند. روی جلد جعبه باید این موارد باشد:

نام محصول
یک تصویر
مشتری هدف آشکار
Value Proposition اصلی برای آن مشتری

این تمرین به ظاهر ساده، یک اثر عمیق دارد: وقتی نماینده تیم جلوی بقیه می‌ایستد و جعبه را Pitch می‌کند، آن‌جا است که Vision واقعی شکل می‌گیرد.

تکنیک Elevator Pitch

ابزار مکمل دیگر، قالب Elevator Pitch از کتاب Crossing the Chasm نوشته Geoffrey Moore است. این قالب روی یک مشتری هدف و یک Value Proposition اصلی تمرکز دارد.

اما نویسندگان هشدار می‌دهند: قالب به تنهایی کافی نیست. پس از پر کردن آن، باید آن را به یک یا دو جمله تبدیل کنید و آن را هم Practical و هم Emotional کنید.

مثال تکاملی که نویسنده می‌آورد:

❌ “هدف ما بهینه‌سازی بدون درز مدیریت جریان کار CPA است.” — نه عملی، نه احساسی
✅ “محصول ما کارهای روزمره و خسته‌کننده محل کار را سریع‌تر می‌کند تا شما وقت بیشتری با خانواده‌تان باشید.” — هم عملی، هم احساسی

فصل ۲: Vision — بخش دوم (Pervasive کردن Vision و استراتژی فنی)

Vision باید Pervasive باشد

نویسندگان با یک سوال فلسفی شروع می‌کنند:

“اگر درختی در جنگل بیفتد و کسی نشنود، آیا صدایی تولید کرده است؟”

همین منطق برای Vision صدق می‌کند. بهترین Vision دنیا، اگر هیچ‌کس آن را نشنود، هیچ فایده‌ای ندارد. اشتباه رایج این است که عده کمی که Vision را می‌فهمند، فرض می‌کنند بقیه هم آن را می‌دانند — و بعد با تعجب می‌پرسند چرا تصمیمات تیم با Vision همسو نیست.

چگونه Vision را در Scrum زنده نگه دارید؟

Scrum به طور طبیعی فرصت‌های متعددی برای تکرار و تقویت Vision فراهم می‌کند:

Sprint Planning: هر Sprint را با یادآوری Vision شروع کنید و توضیح دهید که چطور آیتم‌های بالای Product Backlog به آن Vision متصل هستند. این کار مستقیماً به شکل‌گیری یک Sprint Goal موثرتر کمک می‌کند
Sprint Review: Vision را نه‌فقط با تیم، بلکه با Stakeholderها هم مرور کنید. این جلسه فرصت ارزشمندی است که همه ذینفعان را با مقصد نهایی همسو نگه دارید
Sprint Retrospective: بپرسید آیا Vision هنوز برای همه شفاف است؟ آیا اقدامات Sprint گذشته منعکس‌کننده Vision بودند؟ آیا Stakeholderها Vision را درک می‌کنند؟

نویسنده صادقانه اعتراف می‌کند: “تکرار مداوم Vision گاهی تیم و Stakeholderها را کلافه می‌کند. اما یاد گرفتم که از این احساس ناراحت نشوم. این دقیقاً همان کاری است که یک والد با پیام‌های مهم می‌کند — بارها تکرار می‌کند تا سرانجام در ذهن فرزند جا بیفتد.”

استراتژی فنی: بخشی که Product Ownerها نادیده می‌گیرند

تا اینجا صحبت از استراتژی کسب‌وکار بود. اما نویسندگان یک نکته مهم مطرح می‌کنند که بسیاری از Product Ownerها از آن غفلت می‌کنند: استراتژی فنی.

هر محصول دو لایه دارد:

Business Product: چیزی که مشتری نهایی می‌خرد (مثلاً یک حساب پس‌انداز با سود معین)
Software Product: کانالی که از طریق آن مشتری به آن محصول دسترسی دارد (مثلاً اپلیکیشن موبایل بانک)

نویسندگان یک واقعیت مهم را بیان می‌کنند:

“امروزه رقابت شرکت‌ها در لایه نرم‌افزار است. در یک نقطه‌ای دیگر نرخ سود شما مشتری را جذب نمی‌کند — این اپلیکیشن موبایل شماست که تعیین می‌کند مشتری می‌ماند یا می‌رود.”

Product Owner و دانش فنی

نویسندگان به صراحت از مقاله Forbes نقل می‌کنند:

“مهارت فنی برای یک CEO لزوماً به معنای کد نوشتن نیست. یعنی درک کافی از وضعیت فنی محیط برای اتخاذ تصمیمات استثنایی.”

Product Owner باید به این سوالات استراتژیک-فنی فکر کند:

آیا باید به Cloud مهاجرت کنیم؟
آیا Wearable Devices به محصول ما ارزش اضافه می‌کنند؟
آیا Public API داشته باشیم؟
Native iOS یا HTML5؟

اینها تصمیمات فنی هستند، اما عمیقاً استراتژیک هم هستند. Product Owner نباید در چطور (How) غرق شود، اما باید چه (What) را از منظر فنی هم درک کند.

هشدار مهم: زمان‌بندی استراتژی

نویسندگان یک نکته ظریف اما حیاتی را مطرح می‌کنند:

Feature‌هایی که امروز کاملاً با استراتژی کسب‌وکار و فناوری همسو هستند، ممکن است فردا دیگر همسو نباشند. اولویت‌ها در طول زمان تغییر می‌کنند.

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

Apple Newton و Apple iPod Classic
Google Glass و Google Wave
Amazon Fire Phone

این مثال‌ها پیامی روشن دارند: توقف یک محصول نشانه شکست نیست، بلکه نشانه بلوغ استراتژیک است.

فصل ۳: Value (ارزش) — بخش اول

ارزش کجا خلق می‌شود؟

نویسندگان با یک پاسخ قاطع شروع می‌کنند:

تنها یک لحظه وجود دارد که ارزش واقعاً تحویل می‌شود: Release.

هر چیزی قبل از Release، یک سرمایه‌گذاری است — موجودی انباشته‌شده، پولی که هنوز بازنگشته. اگر شرکت شما دو بار در سال Release می‌کند، یعنی ماه‌ها هزینه می‌کنید بدون اینکه یک ریال برگردد.

مقایسه Waterfall و Scrum از منظر ارزش، بسیار روشنگر است:

Waterfall: Release در آخرین مرحله اتفاق می‌افتد — یعنی ارزش تا آخر تاخیر دارد
Scrum: هر Sprint یک Increment بالقوه قابل‌ Release تولید می‌کند — یعنی ارزش می‌تواند هر ۳۰ روز یا کمتر تحویل شود

معیارهای اشتباه و معیارهای درست

نویسندگان با یک مثال ملموس از یک زنجیره پیتزا استفاده می‌کنند. این مثال یکی از بهترین بخش‌های کتاب است:

اگر شما مدیر بخش تحویل باشید، معیارهایتان اینها هستند:

تعداد پیتزاهای تحویل‌شده در هر سفر
زمان ثبت سفارش
دقت سفارش
هزینه سوخت

اگر شریک/مالک زنجیره پیتزا باشید، معیارهایتان اینها هستند:

درآمد و سود
رضایت مشتری
مشتریان تکراری
سهم بازار

این دو لیست عمدتاً متفاوت هستند. نویسندگان سه دلیل این تفاوت را توضیح می‌دهند:

۱. Efficiency (کارایی): معیارهای بخش تحویل شاید بهینه شوند، اما ضمانتی نیست که به سود کسب‌وکار برسند. مثلاً الگوریتم بهینه‌سازی مسیر ۶۰ ثانیه صرفه‌جویی می‌کند، اما آیا مشتری اصلاً به تحویل سریع‌تر اهمیت می‌دهد؟

۲. Vision: هرچه اعضای تیم Vision و اهداف واقعی سازمان را بهتر درک کنند، تصمیمات بهتری می‌گیرند. مثال واقعی: Domino’s Pizza در سال ۱۹۹۳ تضمین “۳۰ دقیقه یا رایگان” را حذف کرد و آن را با تضمین رضایت مشتری جایگزین کرد — تمرکز از معیار تحویل (زمان) به معیار ارزش (رضایت) تغییر کرد.

۳. Incentive: هر معیاری که به پاداش وصل شود، می‌تواند دستکاری شود. نویسنده مثالی می‌زند از رستورانی که به مشتریان گفت اگر همه امتیازها را “عالی” بزنند، appetizer رایگان می‌گیرند — نتیجه؟ همه “عالی” زدند، اما داده‌های ارزشمندی جمع‌آوری نشد.

Evidence-Based Management (EBMgt)

نویسندگان با الهام از پزشکی مبتنی بر شواهد مفهومی به نام Evidence-Based Management را معرفی می‌کنند که توسط Ken Schwaber حمایت می‌شود.

EBMgt متریک‌ها را در سه Key Value Area (KVA) سازمان‌دهی می‌کند:

KVA اول: Current Value (ارزش جاری)

این KVA وضعیت فعلی سازمان در بازار را نشان می‌دهد و شامل معیارهای زیر است:

Revenue per Employee: درآمد کل تقسیم بر تعداد کارمندان — نشان می‌دهد آیا رشد سازمان با رشد درآمد همگام است
Product Cost Ratio: هزینه کامل توسعه، نگهداری و پشتیبانی محصول — هم هزینه توسعه (Leading) و هم هزینه اجرا در Production (Lagging)
Employee Satisfaction: طبق تحقیقات، بیش از ۵۰٪ از نیروی کار آمریکا درگیر (Engaged) نیستند. نویسنده پیشنهاد می‌کند در پایان هر Sprint Retrospective یک سوال ساده بپرسید: “از ۱ تا ۵، این Sprint برایت چطور بود؟”
Customer Satisfaction: معیار پیشنهادی Net Promoter Score (NPS) است که با یک سوال ساده کار می‌کند: “چقدر احتمال دارد این محصول را به دوستتان معرفی کنید؟” پاسخ‌دهندگان به سه گروه Promoter، Passive و Detractor تقسیم می‌شوند و NPS = درصد Promoter منهای درصد Detractor است

KVA دوم: Time to Market (زمان ورود به بازار)

این KVA توانایی سازمان را در تحویل سریع Feature‌های جدید می‌سنجد:

Release Frequency: چند بار در بازه زمانی مشخص Release می‌کنید؟ این معیار چابکی زمان‌ورود‌به‌بازار را بسیار واضح‌تر از Velocity یا Scope نشان می‌دهد
Release Stabilization: بعد از Feature Freeze، چقدر طول می‌کشد تا نرم‌افزار آماده Release شود؟ هرچه این دوره کوتاه‌تر، بهتر — در Scrum، Increment هر Sprint باید Done باشد و نیازی به Stabilization جداگانه نداشته باشد
Cycle Time: زمان از شروع توسعه یک Feature تا آماده شدن آن برای Production
On-Product Index: چه درصدی از وقت توسعه‌دهندگان روی یک محصول متمرکز است؟ طبق تحقیق Gerald Weinberg، به ازای هر پروژه اضافه‌ای که فرد روی آن کار می‌کند، تا ۲۰٪ از وقتش صرف Context Switching می‌شود — کار روی ۴ پروژه همزمان یعنی ۶۰٪ اتلاف

KVA سوم: Ability to Innovate (توانایی نوآوری)

این KVA نشان می‌دهد سازمان چقدر ظرفیت دارد که چیز جدید بسازد در برابر اینکه صرف نگهداری سیستم‌های قدیمی شود:

Installed Version Index: چند درصد از مشتریان روی آخرین نسخه محصول هستند؟ اگر ۳۰٪ از کاربران روی نسخه قدیمی مانده‌اند، به معنی این است که ۳۰٪ از Feature‌های جدید برایشان ارزش‌آفرین نیست
Usage Index: کدام Feature‌ها بیشترین/کمترین استفاده را دارند؟ طبق مطالعه Standish Chaos، تنها ۳۵٪ از Feature‌ها به‌طور مکرر استفاده می‌شوند
Innovation Rate: چه درصدی از بودجه IT صرف Feature جدید می‌شود در برابر نگهداری و رفع باگ؟ تحقیق Forrester نشان می‌دهد در سال ۲۰۱۰، کمتر از ۳۰٪ بودجه IT صرف Feature جدید می‌شد
Defects: روند افزایش باگ‌ها نشانه کاهش کیفیت سیستم و در نتیجه کاهش ظرفیت نوآوری است

هشدار: Perversion of Metrics

نویسندگان یک اصل مهم را مطرح می‌کنند که Value Neutrality نام دارد:

معیارها باید از قضاوت و تاثیر خارجی آزاد باشند. هیچ داده‌ای بد یا خوب نیست — فقط واقعیت جاری را نشان می‌دهد.

مثال واقعی: یک PMO تصمیم گرفت هر تیمی که Velocity‌اش بیش از ۲۰٪ نوسان داشته باشد، باید جلسه توضیح دهد. نتیجه؟ تیم‌ها شروع کردند Velocity را دستکاری کنند تا از جلسه فرار کنند — معیار، Value Neutral بودن خود را از دست داد.

فصل ۳: Value — بخش دوم (Negative Value، Technical Debt و مدل Kano)

Negative Value: ارزش منفی

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

ارزش منفی دو شکل دارد:

۱. Visible (قابل مشاهده): باگ‌های جدیدی که Feature مهمی را از کار می‌اندازند، Downtime سیستم، کاهش Performance، یا رابط کاربری سنگین‌تر. اینها مستقیماً توسط مشتری تجربه می‌شوند. نکته ظریف: گاهی هزینه رفع باگ از ارزش رفعش بیشتر است — یک شرکت طراح سیستم‌های کارخانجات وقتی دید هزینه آموزش کارکنان در سراسر کشور بعد از هر Release سنگین است، تصمیم گرفت فقط به یک کارخانه Beta ماهانه Release بدهد و هر ۶ ماه یکبار Release سراسری داشته باشد.

۲. Invisible (نامرئی): ارزش منفی داخلی که مشتری آن را نمی‌بیند. مثال‌های کلاسیک:

Feature‌ای که هیچ‌کس استفاده نمی‌کند — پیاده‌سازی، تست، و مستندسازی شد، اما هیچ ارزشی تولید نکرد. بدتر از آن، از این لحظه به بعد باید نگهداری شود
Technical Debt: وقتی تیم را تحت فشار می‌گذارید تا سریع کار کند، کیفیت فنی قربانی می‌شود

Technical Debt: بدهی فنی

نویسندگان یک جمله کلیدی مطرح می‌کنند:

“Technical Debt یعنی Not Done نیست. می‌توانید Done باشید و همزمان Technical Debt داشته باشید.”

این تمایز مهم است. گاهی تصمیم تجاری درستی است که Technical Debt ایجاد کنید — مثلاً برای اولین بودن در بازار، ساختن یک Prototype سریع، یا واکنش به یک رویداد غیرمنتظره. اما اگر آن را فوری پرداخت نکنید، باید آن را با بهره پرداخت کنید.

نمونه‌های Technical Debt:

نبود Automated Test (Unit, Acceptance, Regression)
Code پیچیده با Coupling بالا
Business Logic در جای اشتباه
کد تکراری (Duplicated Code)
نام‌گذاری ناخوانا

ماتریس ۲×۲ فیلیپ کروشتن وضعیت‌ها را خلاصه می‌کند:

	Visible	Invisible
Positive	Feature جدید، قابلیت اضافه	Architecture، Infrastructure، Design، Automation
Negative	باگ، Downtime، Performance ضعیف	Technical Debt، Feature بدون استفاده، هزینه Deployment

ستون Invisible مهم‌ترین بخش این ماتریس است — چون نه مدیران می‌بینند، نه مشتریان، و به همین دلیل نادیده گرفته می‌شود تا زمانی که دیر شده باشد.

مدل Kano و تعریف MVP

نویسندگان مدل Kano را به عنوان ابزاری ساده اما قدرتمند برای تعریف MVP معرفی می‌کنند. این مدل دو محور دارد: نیاز مشتری و سطح رضایت او.

Feature‌ها در سه دسته تقسیم می‌شوند:

دسته	توضیح	مثال خودرو
Basic (پایه)	Feature‌هایی که مشتری فرض می‌کند وجود دارند؛ نبودشان ارزش منفی ایجاد می‌کند	موتور، کمربند ایمنی، فرمان
Performance (عملکرد)	Feature‌هایی که مشتری درخواست می‌دهد؛ هرچه بیشتر، رضایت بیشتر	کولر، سیستم صوتی، GPS
Excitement (هیجان)	Feature‌هایی که مشتری انتظارشان را ندارد اما وقتی می‌بیند ذوق‌زده می‌شود	ادغام Smartphone، ماساژ صندلی، پارک خودکار

MVP آن نقطه‌ای است که در آن Basic Feature‌های کافی، Performance Feature‌های کافی، و چند Excitement Feature را دارید.

نکته مهم: مدل Kano در طول زمان تحول می‌یابد. سیستم ترمز ABS روزی یک Excitement بود، بعد به Performance تبدیل شد، و امروز یک Basic است.

الگوهای MVP

نویسندگان چندین الگوی عملی برای MVP معرفی می‌کنند که اکثراً برای محصولات داخلی سازمان‌ها هم کاربرد دارند:

Promotional MVP: ویدئو، Mockup رابط کاربری، یا کمپین Viral — برای ایجاد هیجان و جمع‌آوری سرمایه قبل از شروع توسعه
Mining MVP: نظرسنجی، Proof of Concept، یا هر چیزی که داده‌های بازار را جمع‌آوری کند. مثال: قبل از سرمایه‌گذاری روی Bitcoin در یک e-commerce، در اولین Sprint یک دکمه “پرداخت با Bitcoin” اضافه کنید که کاربر را به یک نظرسنجی هدایت کند — بدون هیچ توسعه Backend‌ای
Landing Page MVP: یک صفحه که Value Proposition محصول را توضیح می‌دهد؛ پایه‌ای برای جمع‌آوری ترافیک و تولید داده
Wizard of Oz MVP: محصول از بیرون کامل به نظر می‌رسد، اما پشت صحنه انسان‌ها کار را انجام می‌دهند. مثال کلاسیک: Zappos — بنیانگذار عکس کفش‌ها را در فروشگاه‌های محلی گرفت، روی وب گذاشت، و وقتی سفارش می‌آمد خودش می‌رفت کفش می‌خرید و پست می‌کرد. فقط بعد از اثبات تقاضا، Backend واقعی ساخت
Single-Feature MVP: بعد از اینکه محصول در بازار است، یک Feature تکی — حتی یک Product Backlog Item — را Release و اثرش را اندازه بگیرید

Pivot یا Persevere؟

نویسندگان مدل Build-Measure-Learn از کتاب Lean Startup نوشته Eric Ries را با سه ستون Empiricism در Scrum هم‌راستا می‌کنند:

Measure = Transparency
Learn = Inspection
Build = Adaptation

در هر چرخه، یک سوال کلیدی باید پرسیده شود:

اگر داده‌ها فرضیه را تایید کردند یا نتیجه مبهم بود → Persevere (ادامه دهید)
اگر داده‌ها نشان دادند که ارزش مورد انتظار به‌دست نمی‌آید → Pivot (مسیر را عوض کنید)

نویسنده با مثال Paul MacCready این نکته را زنده می‌کند: جایزه ۲ میلیون دلاری برای اولین پرواز انسان‌محور روی کانال مانش بیست سال دست‌نخورده ماند، چون رقبا ماه‌ها طراحی می‌کردند و ثانیه‌ها پرواز. MacCready روش خود را عوض کرد: هواپیمایی ساخت که در چند ساعت قابل بازسازی بود. ۴ بار در روز تست می‌کرد و در ۲۲۳اُمین تلاش موفق شد. سرعت یادگیری بود که تعیین کرد.

فصل ۵: Empiricism (تجربه‌گرایی) — بخش اول

مشکل پیچیدگی

نویسندگان فصل را با یک سناریوی ذهنی جذاب شروع می‌کنند:

تصور کنید مسئول ثابت نگه داشتن دمای یک اتاق کنفرانس در ۲۱ درجه سانتیگراد هستید — بدون ترموستات. مدیر ساختمان از شما می‌خواهد هر صبح تمام متغیرها را از قبل محاسبه کنید.

متغیرهایی که باید پیش‌بینی کنید:

تعداد افراد در اتاق
سطح فعالیت آن‌ها
حجم اتاق
منابع گرمایی دیگر (لپ‌تاپ، پروژکتور)
پیش‌بینی آب‌وهوا
باز یا بسته بودن پنجره‌ها

به نظر می‌رسد اکثر این متغیرها قابل پیش‌بینی هستند — اما اگر فقط نیمی از شرکت‌کنندگان به خاطر ترافیک نیایند چه؟ اگر کسی پنجره را باز کند چه؟ حتی اگر ۹۰٪ متغیرها قابل پیش‌بینی باشند، همان ۱۰٪ باقی‌مانده قدرت آن را دارند که بهترین برنامه را نقش بر آب کنند.

راه‌حل ساده: ترموستات

راه‌حل ساده است — ترموستات. ترموستات هر چند دقیقه یک‌بار دمای فعلی را می‌خواند، با دمای هدف مقایسه می‌کند، و واکنش نشان می‌دهد. اصلاً اهمیتی ندارد چند نفر آمده‌اند، هوا چطور است، یا کسی پنجره را باز کرده. ترموستات با تمام متغیرها کنار می‌آید چون یک حلقه بازخورد (Feedback Loop) دارد.

این استعاره هسته اصلی تفکر Empirical را توضیح می‌دهد:

به جای پیش‌بینی همه متغیرها، یک حلقه بازخورد کوتاه بسازید که شما را از آن‌ها مستقل کند.

تفاوت Complicated و Complex

نویسندگان با استناد به چارچوب Cynefin — که توسط Dave Snowden در IBM ساخته شد — چهار نوع محیط را از هم تفکیک می‌کنند:

محیط	ویژگی	رویکرد درست
Simple	علت و معلول واضح است	بهترین Practice را اعمال کن (Best Practice)
Complicated	علت و معلول وجود دارد اما نیاز به تخصص دارد	تحلیل کن، سپس عمل کن (Good Practice)
Complex	علت و معلول فقط بعد از اتفاق واضح می‌شود	آزمایش کن، مشاهده کن، سپس واکنش نشان بده (Emergent Practice)
Chaotic	هیچ رابطه علت‌ومعلولی قابل تشخیص نیست	فوری عمل کن تا به Complex برگردی (Novel Practice)

توسعه نرم‌افزار تقریباً همیشه در محیط Complex قرار دارد. به همین دلیل است که Waterfall — که برای محیط Complicated طراحی شده — در نرم‌افزار شکست می‌خورد. در Complicated می‌توانید از قبل همه متغیرها را بدانید؛ در Complex نمی‌توانید.

سه ستون Empiricism در Scrum

Scrum بر پایه Empirical Process Control Theory بنا شده که سه ستون اساسی دارد:

۱. Transparency (شفافیت) همه جنبه‌های مهم فرآیند باید برای کسانی که مسئول نتیجه هستند کاملاً قابل مشاهده باشند. بدون شفافیت، Inspection معنایی ندارد. نمونه‌های شفافیت در Scrum: تعریف یکسان از Done، یک زبان مشترک بین اعضای تیم، یک Product Backlog که همه می‌توانند ببینند.

۲. Inspection (بازرسی) کاربران Scrum باید مکرراً Artifact‌ها و پیشرفت را در راستای Sprint Goal بررسی کنند تا انحراف‌های ناخواسته را شناسایی کنند. اما بازرسی بیش از حد — یعنی در هر قدم از کار — خود مانعی برای پیشرفت می‌شود.

۳. Adaptation (انطباق) اگر در بازرسی مشخص شد که فرآیند یا محصول از محدوده قابل قبول خارج شده، تیم باید تنظیماتی انجام دهد. این تنظیم باید سریع باشد تا انحراف بیشتر نشود.

این سه ستون مستقیماً با مدل Build-Measure-Learn که در فصل قبل دیدیم تطابق دارند:
Measure = Transparency
Learn = Inspection
Build = Adaptation

چرا Scrum کار می‌کند؟

نویسندگان با صراحت می‌گویند که Scrum یک Project Management Tool نیست. Scrum یک چارچوب تجربه‌گرا است که با ایجاد حلقه‌های بازخورد کوتاه، سازمان را قادر می‌سازد فرضیه‌هایش را سریع‌تر آزمایش کند.

مقایسه کلیدی بین رویکرد Waterfall و Scrum در محیط‌های پیچیده:

Waterfall فرض می‌کند همه متغیرها از ابتدا قابل پیش‌بینی هستند — مثل مدیری که می‌خواهد بدون ترموستات دمای اتاق را کنترل کند
Scrum با ایجاد Sprint‌های کوتاه، عملاً یک ترموستات می‌سازد که هر ۳۰ روز یا کمتر Feedback جدید دریافت می‌کند و مسیر را تنظیم می‌کند

نکته مهم: در محیط Complex، ریسک‌پذیری ارزشمند است — نه به خاطر بی‌احتیاطی، بلکه چون هر Sprint یک آزمایش کنترل‌شده با هزینه محدود است. شکست در Sprint سوم بسیار ارزان‌تر از شکست بعد از ۱۸ ماه توسعه Waterfall است.

فصل ۵: Empiricism — بخش دوم (پیچیدگی در توسعه محصول)

از اتاق کنفرانس به توسعه محصول

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

متغیرهایی که در هر پروژه نرم‌افزاری باید در نظر بگیرید:

تعداد افراد تیم
Scope (محدوده کار)
بودجه
زمان‌بندی
فناوری
Infrastructure
مهارت‌های افراد
وابستگی به سیستم‌های دیگر
کیفیت
مرخصی و بیماری
خروج اعضای تیم (Attrition)
تغییرات بازار
مقررات و قوانین جدید
دسترسی به افراد کلیدی

حالا همان سوال را بپرسید: کدام یک از اینها ثابت و قابل پیش‌بینی هستند؟

نویسندگان با صراحت پاسخ می‌دهند:

“حتی درباره اینکه آیا Scope قابل پیش‌بینی است، وقت تلف نکنیم.”

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

پیچیده‌تر از اتاق کنفرانس

مقایسه این دو لیست یک نتیجه قطعی دارد:

متغیرهای توسعه محصول به مراتب پیچیده‌تر و کمتر قابل پیش‌بینی از متغیرهای دمای یک اتاق هستند.

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

Scrum به عنوان ترموستات محصول

جمع‌بندی فصل این است که Scrum نه یک روش‌شناسی مدیریت پروژه، بلکه یک سیستم بازخورد است — درست مثل ترموستات:

ترموستات	Scrum
دما را هر چند دقیقه می‌خواند	هر Sprint یک Increment قابل بازرسی تولید می‌کند
با هدف مقایسه می‌کند	با Sprint Goal و Product Vision مقایسه می‌شود
گرم‌کن یا خنک‌کن را تنظیم می‌کند	Product Backlog تنظیم و اولویت‌بندی می‌شود
به متغیرهای ناپیش‌بینی اهمیت نمی‌دهد	تیم با هر تغییری سازگار می‌شود

هر بار که یک Increment کار‌شده بازرسی می‌شود، بخشی از پیچیدگی کاهش می‌یابد — چون آنچه نمی‌دانستیم به آنچه می‌دانیم تبدیل شده است.

ریسک‌پذیری در محیط پیچیده

نویسندگان یک نکته ضدشهودی مطرح می‌کنند:

ریسک‌پذیری در محیط Complex یک مزیت است، نه یک ضعف.

در یک محیط ساده (Simple)، ریسک‌پذیری بی‌معنی است چون پاسخ از قبل مشخص است. اما در توسعه نرم‌افزار که محیطی Complex است، هر Sprint یک آزمایش کنترل‌شده با هزینه محدود است. شکست در Sprint سوم یعنی یادگیری ارزشمند با هزینه‌ای بسیار کمتر از کشف اشتباه بعد از ۱۸ ماه توسعه Waterfall.

این نگاه، تعریف “موفقیت” را هم تغییر می‌دهد. موفقیت دیگر به معنای “پایبندی به برنامه اولیه” نیست؛ بلکه به معنای سریع‌ترین یادگیری ممکن است.

Quiz فصل ۵ — مرور پاسخ‌ها

نویسندگان در پایان فصل پاسخ سوالات اولیه را می‌دهند:

گزاره	پاسخ
Agile فقط برای محصولات ساده مثل وب‌سایت‌ها مناسب است	مخالف — Agile برای محیط‌های Complex طراحی شده
اگر افراد درست باشند و زمان کافی داشته باشند، می‌توانند همه متغیرها را پیش‌بینی کنند	مخالف — در محیط Complex این ذاتاً غیرممکن است
کارآمدترین رویکرد برای مشکل ساده، Inspect and Adapt مداوم است	مخالف — برای Simple از Best Practice استفاده کنید
ریسک‌پذیری در مشکلات Complex خوب است	موافق
هر بار که Increment توسعه‌یافته بازرسی شود، پیچیدگی کاهش می‌یابد	موافق

فصل ۶: Scrum

بخش اول — چرا یک Framework؟ (و نه یک Process)

فصل ۶ با یک Quiz آغاز می‌شود تا ذهن خواننده را برای سوالات بنیادی آماده کند. پیش از هر چیز، با مهم‌ترین تمایز مفهومی فصل شروع می‌کنیم.

Scrum یک Framework است، نه یک Process

نویسنده صراحتاً می‌گوید که Scrum عمداً از کلمه «Process» پرهیز می‌کند. اگر در یک دادگاه هم این ادعا را مطرح کنی، احتمالاً بازنده‌ای — چون Scrum رویدادهای مرتب، نقش‌ها، و Artifact دارد؛ دقیقاً شبیه یک Process. اما نکته کلیدی در اینجا Ownership است.

سوال اساسی این است: چه کسی باید واقعاً صاحب Process باشد؟

مدیریت؟
PMO سازمان؟
یک کتاب یا راهنما؟
Schwaber و Sutherland؟

پاسخ هیچ‌کدام از اینها نیست. Scrum Team باید صاحب Process باشد.

هر تیم، هر محصول، هر شرکت متفاوت است و Process باید از دل نیازهای منحصر‌به‌فرد آنها ظهور کند (Emerge). با این حال، مفید است که تیم‌ها از یک نقطه شروع داشته باشند — یک مجموعه حداقلی از قوانین؛ یعنی همان Framework.

متافور اجاره در برابر خرید خانه

نویسنده یک تمثیل قوی ارائه می‌دهد:

اگر خانه‌ات را اجاره کرده باشی و چیزی خراب شود، چه می‌کنی؟ به موجر زنگ می‌زنی و شکایت می‌کنی. احساس می‌کنی قربانی هستی.

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

این دقیقاً همان چیزی است که با Process‌ها هم اتفاق می‌افتد:

اگر Process از خارج از تیم تحمیل شود → تیم در زمان بروز مشکل، مدیریت/PMO را مقصر می‌داند و Ownership نمی‌گیرد.
اگر تیم Scrum را به عنوان یک نقطه شروع ببیند → وقتی چیزی خراب شود، جایی برای انداختن مقصر ندارد جز خودش. این مواد خام ضروری برای Accountability و Self-Organization است.

تله‌ی کپی از تیم Pilot

نویسنده یک ضد‌الگوی رایج را هشدار می‌دهد:

تصور کن یک تیم Pilot در سازمان با Scrum موفق می‌شود. مدیریت می‌خواهد همین را به تمام تیم‌ها منتقل کند و می‌پرسد:

«چه عنوانی داشت Scrum Master شما؟»
«از چه ابزاری استفاده کردید؟»
«چه ساعتی Daily Scrum داشتید؟»
«از چه رنگی استیکر استفاده کردید؟»

این یعنی بازگشت به اجاره‌ی یک Process. تیم‌های بعدی همان حس Ownership را نخواهند داشت و دوباره در دام blame و انتقاد از «Scrum Process» می‌افتند.

نویسنده اشاره می‌کند که اگر در فضای آنلاین دنبال انتقادات ضد‌Scrum بگردی، متوجه می‌شوی که شکایات معمولاً درباره Framework Elements نیستند، بلکه درباره Practice‌هایی هستند که توسط افراد خارج از تیم (مدیران، PMO‌ها، Agile Coaches) روی Scrum سوار شده‌اند.

سه پایه‌ی Scrum

پایه اول — Transparency (شفافیت)

از Scrum Guide:

«جنبه‌های مهم Process باید برای کسانی که مسئول نتیجه هستند، قابل مشاهده باشند. شفافیت مستلزم تعریف این جنبه‌ها بر اساس یک استاندارد مشترک است تا ناظران درک یکسانی از آنچه می‌بینند داشته باشند.»

دو نمونه‌ی عملی که کتاب ذکر می‌کند:

یک زبان مشترک برای توصیف Process باید بین تمام اعضا وجود داشته باشد.
کسانی که کار می‌کنند و کسانی که Increment را بررسی می‌کنند، باید یک تعریف مشترک از Done داشته باشند.

نویسنده یک تمثیل دقیق می‌آورد:

نبود Transparency مثل گذاشتن یک دستمال خیس روی ترموستات است. ترموستات داده‌ی نادرست می‌خواند، بر اساس همان بازرسی می‌کند، و در نهایت به شکل اشتباه واکنش نشان می‌دهد.

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

پایه دوم — Inspection (بازرسی)

از Scrum Guide:

«کاربران Scrum باید مکرراً Artifact‌های Scrum و پیشرفت به سمت Sprint Goal را بازرسی کنند تا انحرافات ناخواسته را شناسایی کنند. بازرسی نباید به قدری مکرر باشد که خودِ کار را مختل کند.»

نکته‌ی ظریفی که نویسنده اضافه می‌کند این است: بازرسی باید توسط بازرسان ماهر و در محل کار انجام شود.

تصور کن سازمانی هست که هیچ چیزی برای پنهان کردن ندارد (Transparency کامل) و توانایی تغییر هم دارد (Adaptation). اما هرگز داده‌ها را به شکل منسجم تحلیل نمی‌کند. نتیجه؟ افراد احساس می‌کنند باید تغییر کنند، اما شواهد کافی ندارند و تغییر واقعی اتفاق نمی‌افتد.

Feedback Loop‌های کوتاه و Information Radiator‌های شفاف، ستون فقرات هر فرآیند تجربی هستند.

پایه سوم — Adaptation (تطبیق)

از Scrum Guide:

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

چهار رویداد رسمی Scrum دقیقاً برای همین Inspection و Adaptation طراحی شده‌اند:

Sprint Planning
Daily Scrum
Sprint Review
Sprint Retrospective

نویسنده اشاره می‌کند: تصور کن سازمانی داده‌های دقیق دارد و آن‌ها را به درستی تحلیل می‌کند، اما هیچ‌کس اختیار یا اراده‌ای برای تغییر ندارد. این یعنی Transparency و Inspection بی‌فایده‌اند.

Thomas Edison جمله‌ای دارد که نویسنده آن را مستقیم نقل می‌کند: «Vision without execution is hallucination.»

ارتباط سه پایه با یکدیگر

این سه پایه مثل یک سازه‌ی معماری هستند — اگر هر کدام حذف شود، کل ساختار فرو می‌ریزد:

پایه	اگر نباشد
Transparency	داده‌ها واقعیت را منعکس نمی‌کنند؛ بازرسی و تطبیق هر دو بی‌معنا می‌شوند
Inspection	داده وجود دارد اما تحلیل نمی‌شود؛ تغییر بدون شواهد کافی انجام می‌گیرد
Adaptation	همه چیز می‌دانند چه مشکلی وجود دارد، اما هیچ اقدامی نمی‌شود

این سه پایه مستقیماً با اصطلاح‌شناسی فصل‌های قبلی کتاب هم همخوانی دارد: Measure = Transparency، Learn = Inspection، Build = Adaptation — همان Build-Measure-Learn Loop که از Eric Ries آمده.

نقش‌های Scrum

نقش اول — Product Owner

از Scrum Guide:

«Product Owner مسئول به حداکثر رساندن ارزش محصول ناشی از کار Development Team است. Product Owner تنها شخصی است که مسئولیت مدیریت Product Backlog را بر عهده دارد.»

مدیریت Product Backlog شامل این موارد است:

بیان شفاف Product Backlog Item‌ها
مرتب‌سازی آیتم‌ها برای دستیابی به بهترین نتیجه
اطمینان از اینکه Product Backlog برای همه قابل مشاهده، شفاف و واضح است
اطمینان از اینکه Development Team آیتم‌ها را به اندازه کافی درک می‌کند

نویسنده تأکید می‌کند: Product Owner یک نفر است، نه یک کمیته. ممکن است خواسته‌های یک کمیته را نمایندگی کند، اما کسانی که می‌خواهند اولویت آیتمی را تغییر دهند، باید مستقیماً با همین یک نفر صحبت کنند.

Product Owner به مثابه پادشاه

نویسنده تصویری جالب ترسیم می‌کند — Product Owner را با یک تاج نشان می‌دهد:

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

این تفاوت بنیادی با Project Manager سنتی است. Project Manager نگران Scope، Schedule، و Budget است. اما Product Owner نگران این است که آیا محصول درستی ساخته می‌شود و آیا ارزش واقعی برای کاربران ایجاد می‌کند یا نه.

Domain Expert بودن — ضرورت، نه لوکس

نویسنده یک تجربه واقعی نقل می‌کند: در پروژه‌ای برای Swiss Postal Services که بیش از ۲۰,۰۰۰ نفر از سیستم استفاده می‌کردند، کارکنان پستی به طور منظم در Product Backlog Refinement، کارگاه‌های UI، و Sprint Review‌ها شرکت داده می‌شدند. هدف صرفاً جایگزینی سیستم قدیمی نبود، بلکه ایجاد ارزش برای هزاران نفر بود.

واقعیت تلخ:

Product Owner که Proxy است — فقط درخواست‌های ذینفعان را جمع می‌کند و بر اساس بلندترین صدا (Squeaky Wheel) اولویت‌بندی می‌کند.
Product Owner که واقعاً صاحب محصول است — با اتکا به دانش دامنه، سریع تصمیم می‌گیرد و با ذینفعان همگام می‌شود.

البته نویسنده واقع‌بین است: درخواست اینکه Product Owner همه چیز را بداند تقریباً غیرممکن است. راه‌حل؟ استفاده از Subject Matter Experts (SME) به عنوان اهرم — حتی ایجاد خطوط ارتباطی مستقیم بین Development Team و ذینفعان.

نقش دوم — Development Team

از Scrum Guide:

«Development Team از متخصصانی تشکیل شده که کار تحویل یک Increment آماده‌ی انتشار از محصول Done را در پایان هر Sprint انجام می‌دهند.»

ویژگی‌های کلیدی Development Team:

Self-Organizing — هیچ‌کس، حتی Scrum Master، به آن‌ها نمی‌گوید چگونه Product Backlog را به Increment تبدیل کنند
Cross-Functional — تمام مهارت‌های لازم برای ساخت Increment درون تیم وجود دارد
بدون عنوان — Scrum هیچ عنوانی برای اعضا به رسمیت نمی‌شناسد، صرف‌نظر از نوع کار
بدون زیرتیم — مثل Testing Team، Architecture Team و غیره
Accountability کل Increment با تیم به عنوان یک کل است، نه با افراد جداگانه

تعامل روزانه‌ی Product Owner با Development Team

نویسنده یک هشدار صریح می‌دهد: از Hand-off الزامات پرهیز کن.

به جای اینکه Product Owner الزامات را تعریف و تحویل دهد، باید:

در Refinement، درک و ارزش آیتم‌ها را منتقل کند، نه صرفاً توضیح دهد
به Development Team اعتماد کند تا راه‌حل را خودشان پیدا کنند
در طول Sprint، در دسترس باشد و Feedback بدهد

این رویکرد دو مزیت مهم دارد: Development Team Ownership قوی‌تری روی آیتم‌ها پیدا می‌کند، و Product Owner آزاد می‌شود تا روی کارهای استراتژیک‌تر تمرکز کند — تحلیل بازار، رقبا، صحبت با فروش و مارکتینگ، و هماهنگی با ذینفعان.

Development Team و محصول — یک قانون ساده

نویسنده یک اصل بنیادی را با تمثیل آشپزی توضیح می‌دهد:

تصور کن با دوستانت می‌خواهید یک مهمانی بزرگ کیترینگ کنید. اگر دو نفر از دوستانت نتوانند بیایند، یا انبار مواد اولیه ناقص باشد، یا تیم مهارت‌های لازم برای منوی درخواستی را نداشته باشد — چه اتفاقی می‌افتد؟

قانون:

آنچه در Development Team هست می‌تواند در محصول باشد؛ آنچه نیست، اغلب نمی‌تواند.

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

Sandy Mamoli و David Mole معتقدند ۶۰٪ موفقیت به افرادی بستگی دارد که کار را انجام می‌دهند. شرکت‌هایی که این را درک کرده‌اند، تیم‌ها را Fund می‌کنند، نه پروژه‌ها را.

نقش سوم — Scrum Master

از Scrum Guide:

«Scrum Master مسئول ترویج و پشتیبانی از Scrum است. Scrum Master یک Servant-Leader برای Scrum Team است.»

سه حوزه خدمت Scrum Master:

به Product Owner:

اطمینان از اینکه اهداف، Scope، و دامنه‌ی محصول برای همه قابل فهم است
کمک به یافتن تکنیک‌های موثر برای مدیریت Product Backlog
اطمینان از اینکه Product Owner می‌داند چطور Product Backlog را برای حداکثرسازی ارزش مرتب کند
تسهیل رویدادهای Scrum در صورت نیاز

به Development Team:

Coaching در زمینه Self-Organization و Cross-Functionality
کمک به ساخت محصولات با ارزش بالا
حذف موانع (Impediments) از مسیر پیشرفت
Coaching در محیط‌هایی که Scrum هنوز به درستی پذیرفته نشده

به سازمان:

رهبری و Coaching سازمان در مسیر پذیرش Scrum
کمک به کارکنان و ذینفعان در درک توسعه‌ی تجربی محصول
ایجاد تغییراتی که بهره‌وری Scrum Team را افزایش دهند

آیا Scrum Master باید دامنه‌ی کسب‌وکار را بشناسد؟

نویسنده پاسخ جالبی می‌دهد: ضرری ندارد، اما ضرورت هم ندارد. بلکه ممکن است عدم آشنایی با دامنه حتی مزیت باشد — چون Scrum Master را آزاد می‌گذارد تا روی Facilitation، Coaching، دینامیک تیم، و شناسایی شکاف‌های Process تمرکز کند بدون اینکه درگیر جزئیات فنی دامنه شود.

تفکیک مسئولیت‌ها — زیبایی ساختار Scrum

نقش	مسئولیت اصلی
Product Owner	کیفیت محصول — ساختن محصول درست با ارزش واقعی
Development Team	کیفیت فنی — ساختن محصول به روش درست
Scrum Master	تسهیل — اطمینان از اینکه هر دو طرف کارشان را می‌توانند انجام دهند

Artifact‌های Scrum

ارتباط سه Artifact با یکدیگر

Scrum تنها سه Artifact اجباری دارد: Product Backlog، Sprint Backlog، و Increment. این سه به شکل یک زنجیره به هم وصل‌اند:

Increment از Sprint Backlog تولید می‌شود
Sprint Backlog از Product Backlog استخراج می‌شود
Product Backlog بر اساس Feedback از Increment بازنگری می‌شود

این یک چرخه‌ی بسته است — هر Artifact ورودی Artifact بعدی است.

Artifact اول — Product Backlog

از Scrum Guide:

«Product Backlog یک لیست مرتب‌شده از هر آن چیزی است که برای محصول لازم است. این تنها منبع الزامات برای هر تغییری است که باید در محصول ایجاد شود. Product Owner مسئول Product Backlog است، شامل محتوا، دسترس‌پذیری، و مرتب‌سازی آن.»

چند نکته‌ی مهم:

Product Backlog هرگز کامل نیست. اولین نسخه‌اش شامل الزامات اولیه و بهترین‌ درک آن لحظه است.
این یک Artifact زنده است — تغییرات در نیازهای کسب‌وکار، شرایط بازار، یا تکنولوژی مستقیماً روی آن تأثیر می‌گذارند.
آیتم‌های بالای Product Backlog معمولاً شفاف‌تر و با جزئیات بیشترند؛ آیتم‌های پایین‌تر مبهم‌ترند و با گذر زمان و نزدیک‌تر شدن، Refine می‌شوند.

هر Product Backlog Item چهار ویژگی دارد:

Description — توضیح آیتم
Order — جایگاه در لیست
Estimate — برآورد تلاش لازم
Value — ارزش کسب‌وکاری

این فرآیند به معنای افزودن جزئیات، برآورد، و مرتب‌سازی آیتم‌هاست. نویسنده تأکید می‌کند که Refinement نه یک رویداد رسمی Scrum است و نه یک فعالیت یک‌باره — یک فعالیت مستمر است که در طول Sprint انجام می‌شود.

قانون عملی: Development Team معمولاً نباید بیش از ۱۰٪ از ظرفیتش را صرف Refinement کند.

Artifact دوم — Sprint Backlog

از Scrum Guide:

«Sprint Backlog مجموعه‌ای از Product Backlog Item‌های انتخاب‌شده برای Sprint است، به علاوه یک Plan برای تحویل Increment و تحقق Sprint Goal.»

نکات کلیدی:

Sprint Backlog یک پیش‌بینی توسط Development Team است درباره‌ی اینکه چه Functionality‌ای در Increment بعدی خواهد بود.
این Artifact متعلق به Development Team است، نه Product Owner.
فقط Development Team می‌تواند در طول Sprint محتوای آن را تغییر دهد.
Sprint Backlog باید به اندازه کافی جزئیات داشته باشد تا پیشرفت روزانه در Daily Scrum قابل درک باشد.

Sprint Goal — چسب Sprint

Sprint Goal هدف واحدی است که با اجرای Sprint Backlog به دست می‌آید. این هدف به Development Team انعطاف می‌دهد — اگر در طول Sprint اطلاعات جدیدی به دست آمد، تیم می‌تواند نحوه‌ی رسیدن به هدف را تنظیم کند بدون اینکه کل Sprint دچار هرج و مرج شود.

Sprint Goal همچنین یک عامل انسجام در تیم است: به جای اینکه هر نفر روی یک Feature مجزا کار کند، همه به سمت یک هدف مشترک حرکت می‌کنند.

Artifact سوم — Increment

از Scrum Guide:

«Increment مجموع تمام Product Backlog Item‌های کامل‌شده در طول یک Sprint است، به علاوه‌ی ارزش تمام Increment‌های قبلی. در پایان Sprint، Increment جدید باید Done باشد — یعنی قابل استفاده و مطابق با تعریف Done.»

این مهم‌ترین تأکید نویسنده است: Increment باید واقعاً Done باشد. نه «تقریباً Done»، نه «۹۰٪ Done». Done یعنی قابل انتشار — حتی اگر تصمیم به انتشار نگیرید.

Definition of Done — پایه‌ی شفافیت

Definition of Done یک درک مشترک است درباره‌ی اینکه چه زمانی کار «تمام» است. بدون این تعریف مشترک:

Transparency از بین می‌رود — هر نفر «Done» را متفاوت تفسیر می‌کند
Increment قابل اطمینان نیست
فرآیند تجربی کار نمی‌کند

نویسنده هشدار می‌دهد: Undone Work — کاری که به تعریف Done نرسیده — یک بدهی فنی (Technical Debt) است که با گذر زمان انباشته می‌شود و توانایی تیم برای نوآوری را از بین می‌برد. این مستقیماً به همان Ability to Innovate که در فصل ۳ دیدیم مرتبط است.

جمع‌بندی ساختار Artifact‌ها

Artifact	صاحب	هدف
Product Backlog	Product Owner	چه چیزی ساخته شود
Sprint Backlog	Development Team	چگونه در این Sprint ساخته شود
Increment	Scrum Team	شواهد ملموس از ارزش تحویل‌شده

رویدادهای Scrum

Sprint — ظرف همه‌ی رویدادها

Sprint قلب Scrum است. همه‌ی رویدادهای دیگر درون Sprint اتفاق می‌افتند. Sprint یک Time-box است — حداکثر یک ماه، اما معمولاً دو هفته. این Time-box ثابت است و در میانه راه کوتاه یا بلند نمی‌شود.

چرا Time-box مهم است؟ چون پیش‌بینی‌پذیری ایجاد می‌کند. هر ذینفع می‌داند که حداکثر تا چه زمانی یک Increment قابل بررسی خواهد بود. همچنین هزینه‌ی ریسک را محدود می‌کند — اگر اشتباهی رخ دهد، در کمتر از یک ماه قابل شناسایی و اصلاح است.

قوانین ثابت Sprint:

هیچ تغییری در Sprint Backlog نباید Sprint Goal را به خطر بیندازد
ترکیب و کیفیت تیم ثابت می‌ماند
اگر Sprint Goal منسوخ شود، فقط Product Owner می‌تواند Sprint را لغو کند

رویداد اول — Sprint Planning

Sprint Planning آغازگر هر Sprint است. کل Scrum Team در این رویداد شرکت می‌کند. Time-box آن برای یک Sprint یک‌ماهه حداکثر ۸ ساعت است.

دو سوال اساسی در Sprint Planning پاسخ داده می‌شود:

سوال اول: «چه چیزی می‌توان در این Sprint تحویل داد؟»

Product Owner بالاترین آیتم‌های Product Backlog را توضیح می‌دهد. Development Team پیش‌بینی می‌کند که چه Functionality‌ای می‌تواند در این Sprint Done شود. بر اساس این بحث، Sprint Goal شکل می‌گیرد — یک هدف واحد که جهت کلی Sprint را تعریف می‌کند.

سوال دوم: «چگونه به این هدف می‌رسیم؟»

Development Team آیتم‌های انتخاب‌شده را تجزیه می‌کند — اغلب به Task‌هایی با حداکثر یک روز کاری. این طراحی ممکن است در طول Sprint تغییر کند و این کاملاً طبیعی است.

نکته‌ی مهم: Product Owner باید در دسترس باشد تا سوالات را پاسخ دهد، اما نباید در جزئیات نحوه‌ی اجرا دخالت کند. این حوزه‌ی Development Team است.

رویداد دوم — Daily Scrum

Daily Scrum یک رویداد ۱۵ دقیقه‌ای است که هر روز در ساعت و مکان مشخص برگزار می‌شود. فقط اعضای Development Team در آن شرکت می‌کنند.

سه سوال کلاسیک Daily Scrum:

دیروز چه کاری برای رسیدن به Sprint Goal انجام دادم؟
امروز چه کاری انجام می‌دهم؟
آیا مانعی وجود دارد که جلوی پیشرفتم را بگیرد؟

اما نویسنده تأکید می‌کند که این سه سوال الزامی نیستند. آنچه الزامی است این است که Daily Scrum یک Inspection از پیشرفت به سمت Sprint Goal باشد و یک Plan برای ۲۴ ساعت بعدی ایجاد کند.

یک سوءتفاهم رایج: Daily Scrum یک Status Meeting برای مدیران نیست. این رویداد متعلق به Development Team است — برای هماهنگی درونی تیم، نه گزارش به خارج از تیم.

فایده‌ی اصلی: Daily Scrum کمک می‌کند که Impediment‌ها زودتر شناسایی شوند. Scrum Master مسئول حذف این موانع است، اما تشخیص آن‌ها در این رویداد اتفاق می‌افتد.

رویداد سوم — Sprint Review

Sprint Review در پایان هر Sprint برگزار می‌شود. Time-box آن برای Sprint یک‌ماهه حداکثر ۴ ساعت است. مهم‌ترین ویژگی این رویداد: ذینفعان دعوت می‌شوند.

هدف Sprint Review این نیست که Development Team کار خود را به نمایش بگذارد تا تحسین شود. هدف یک بحث تجربی است:

چه چیزی Done شد؟ چه چیزی Done نشد؟
چه تغییراتی در محیط بازار یا بودجه رخ داده؟
Product Backlog بر اساس این اطلاعات چطور باید به‌روزرسانی شود؟
بعدی‌ترین گام‌های با ارزش چیستند؟

نویسنده روی یک نکته‌ی ظریف تأکید می‌کند: Sprint Review یک Demo Session نیست — یک Feedback Loop است. تفاوت اساسی اینجاست:

Demo Session	Sprint Review
یک‌طرفه — تیم نشان می‌دهد	دوطرفه — گفتگو و تبادل نظر
هدف: تأیید گرفتن	هدف: یادگیری و تطبیق
ذینفعان ناظرند	ذینفعان مشارکت‌کننده‌اند

هر چقدر ذینفعان بیشتر در Sprint Review مشارکت کنند، احساس مالکیت بیشتری روی محصول خواهند داشت — و پس از انتشار کمتر می‌توانند شکایت کنند.

رویداد چهارم — Sprint Retrospective

Sprint Retrospective پس از Sprint Review و پیش از Sprint Planning بعدی برگزار می‌شود. Time-box آن برای Sprint یک‌ماهه حداکثر ۳ ساعت است.

اگر Sprint Review درباره‌ی محصول است، Sprint Retrospective درباره‌ی تیم و Process است.

سه حوزه‌ی بررسی:

افراد — تعاملات و همکاری
فرآیندها و ابزارها — چه چیزی کار کرد، چه چیزی نکرد
تعریف Done — آیا باید به‌روزرسانی شود؟

نتیجه‌ی مورد انتظار: حداقل یک اقدام بهبودی (Improvement Action) که در Sprint بعدی پیاده‌سازی می‌شود. نه یک لیست بلند از مشکلات — یک تغییر واقعی و قابل اندازه‌گیری.

نویسنده روی یک مشکل رایج انگشت می‌گذارد: بسیاری از تیم‌ها Sprint Retrospective را برگزار می‌کنند، از همان مشکلات قدیمی حرف می‌زنند، اما هیچ تغییری نمی‌دهند. این Retrospective نیست — این شکایت‌کردن است.

ارتباط رویدادها با سه پایه‌ی Scrum

نویسنده این ارتباط را صریح بیان می‌کند:

رویداد	Pillar
Sprint	ظرف همه‌ی چرخه‌های Transparency، Inspection، Adaptation
Sprint Planning	Adaptation — تطبیق بر اساس آنچه می‌دانیم
Daily Scrum	Inspection — بازرسی روزانه‌ی پیشرفت
Sprint Review	Inspection + Adaptation — بازرسی محصول و تطبیق Product Backlog
Sprint Retrospective	Inspection + Adaptation — بازرسی Process و تطبیق آن

ارزش‌های Scrum و بخش پایانی فصل ۶

پنج ارزش بنیادین Scrum

نویسنده در این بخش توضیح می‌دهد که Pillar‌های سه‌گانه (Transparency، Inspection، Adaptation) به تنهایی کافی نیستند. اگر فرهنگ تیم آن‌ها را حمایت نکند، هر سه فرو می‌ریزند. اینجاست که پنج ارزش Scrum وارد می‌شوند:

۱. Commitment (تعهد)

اعضای Scrum Team شخصاً متعهد می‌شوند که به اهداف Scrum Team دست یابند. نویسنده تأکید می‌کند که Commitment به معنای تضمین نتیجه نیست — یعنی تعهد به تلاش واقعی برای رسیدن به Sprint Goal. تیم‌هایی که Sprint Goal را صرفاً به عنوان یک لیست وظایف می‌بینند، این ارزش را درک نکرده‌اند.

۲. Courage (شجاعت)

اعضای Scrum Team باید شجاعت داشته باشند که کارهای درست انجام دهند و مشکلات دشوار را مطرح کنند. این ارزش مستقیماً به Transparency گره خورده است. بدون شجاعت، افراد مشکلات را پنهان می‌کنند، Impediment‌ها گفته نمی‌شوند، و Retrospective به یک جلسه‌ی تعریف و تمجید تبدیل می‌شود.

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

۳. Focus (تمرکز)

همه روی کار Sprint و اهداف Scrum Team تمرکز می‌کنند. این ارزش مستقیماً با مفهوم On-Product Index که در فصل ۳ دیدیم در ارتباط است. Task Switching دشمن Focus است و Focus دشمن Task Switching.

نویسنده یادآوری می‌کند: Development Team نمی‌تواند همزمان روی چند محصول یا چند Sprint Goal کار کند و انتظار داشته باشد که کیفیت یا سرعت حفظ شود.

۴. Openness (بازبودن)

Scrum Team و ذینفعان باید درباره‌ی تمام کارها و چالش‌ها روشن و صادق باشند. این ارزش زیربنای Transparency است. اگر اعضای تیم نگران قضاوت شدن باشند، اطلاعات واقعی پنهان می‌شود و Empiricism از کار می‌افتد.

Openness همچنین یعنی پذیرش Feedback از Sprint Review — حتی وقتی آن Feedback نشان می‌دهد که مسیر اشتباه بوده.

۵. Respect (احترام)

اعضای Scrum Team به یکدیگر به عنوان افراد توانمند و مستقل احترام می‌گذارند. این ارزش زمینه‌ساز Self-Organization است. Development Team زمانی می‌تواند خودسازمان‌ده باشد که Product Owner و Scrum Master به توانایی‌های آن‌ها اعتماد داشته باشند و در کارشان دخالت نکنند.

ارتباط ارزش‌ها با انگیزه‌ی درونی

نویسنده در اینجا دایره را می‌بندد و به مفهومی که در فصل ۳ مطرح کرده برمی‌گردد — مدل Dan Pink در کتاب Drive:

سه عنصر انگیزه‌ی درونی:
Autonomy — میل به خودراهبری
Mastery — اشتیاق برای بهتر شدن مستمر
Purpose — احساس اینکه کارت چیزی فراتر از خودت ایجاد می‌کند

Scrum هر سه را به شکل ساختاری تزریق می‌کند:

عنصر Pink	چگونه در Scrum تجلی می‌یابد
Autonomy	Development Team Self-Organizing است — هیچ‌کس به آن‌ها نمی‌گوید چگونه کار کنند
Mastery	Sprint Retrospective یک چرخه‌ی بهبود مستمر است — تیم هر Sprint بهتر از قبل می‌شود
Purpose	Sprint Goal و Product Vision معنای واقعی کار را روشن می‌کنند — تیم می‌داند چرا کار می‌کند

جمع‌بندی فصل — Scrum به مثابه یک سیستم منسجم

نویسنده فصل را با یک نگاه کلی می‌بندد. Scrum نه یک متدولوژی گام‌به‌گام است، نه یک ابزار مدیریت پروژه. بلکه یک سیستم منسجم است که اجزایش یکدیگر را تقویت می‌کنند:

ارزش‌ها  →  پایه‌های سه‌گانه را زنده نگه می‌دارند
پایه‌ها   →  از طریق رویدادها اجرا می‌شوند
رویدادها  →  Artifact‌ها را به‌روزرسانی می‌کنند
Artifact‌ها →  توسط نقش‌ها مدیریت می‌شوند
نقش‌ها   →  با ارزش‌ها هدایت می‌شوند  ←  دایره کامل می‌شود

نویسنده با یک هشدار جدی فصل را تمام می‌کند: برداشتن یا تغییر هر عنصر از این سیستم، کل منطق آن را مختل می‌کند. این همان چیزی است که در اکثر پیاده‌سازی‌های ناموفق Scrum می‌بینیم — نه Scrum شکست خورده، بلکه چیزی به نام Scrum پیاده شده که چندین عنصر کلیدی‌اش حذف یا تحریف شده.

فصل ۷: مدیریت Product Backlog

بلوک مفهومی اول — «الزام چیست؟ و ماهیت Product Backlog»

۱. الزام (Requirement) چیست؟

نویسنده با یک نکتهٔ اساسی آغاز می‌کند که بسیاری از تیم‌های نرم‌افزاری از آن غافلند:

یک الزام، یک سند نیست. وجود دارد، چه ثبت شده باشد چه نباشد. حتی ممکن است هنوز کشف نشده باشد.

این جمله بار فلسفی سنگینی دارد. تیم‌هایی که فکر می‌کنند اگر چیزی در مستند نباشد «وجود ندارد»، در یک توهم بزرگ زندگی می‌کنند. الزام واقعی در ذهن ذینفع است، نه در فایل Word.

تمام الزامات در سه دستهٔ کلی قرار می‌گیرند:

دسته	توضیح	مثال
Functional	چگونه/چرا کاربر از سیستم استفاده می‌کند	ثبت‌نام کاربر
Nonfunctional	چگونه سیستم باید رفتار کند	Performance، Scalability، Security
Business Rules	قوانین حاکم بر دامنهٔ کسب‌وکار	فرمول‌های مالی، قوانین قانونی

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

راه‌حل عملی: به جای نوشتن مستندات پیچیده، یک لیست بزرگ کار (to-do list) برای محصول بسازید. هدف، فراموش نکردن سؤالات درست است، نه ثبت جزئیات. جزئیات بعداً، در زمان مناسب و از طریق گفتگو کشف می‌شوند.

در Scrum، این لیست، Product Backlog نام دارد.

۲. Product Backlog — تعریف رسمی و کاربرد واقعی

از Scrum Guide:

Product Backlog یک لیست مرتب‌شده از تمام چیزهایی است که باید در محصول وجود داشته باشند. این لیست تنها منبع الزامات برای هر تغییری در محصول است. Product Owner مسئول آن است.

چه چیزی می‌تواند وارد Product Backlog شود؟

Feature Requests — درخواست‌های ذینفعان (مثلاً «می‌خواهم بتوانم لیست را مرتب کنم»)
Nonfunctional Requirements — کیفیت‌های سیستمی (مثلاً «پشتیبانی از ۲۰۰۰ کاربر همزمان»)
Experiments — ابزارهای آزمایشی برای تست بازار (مثلاً UI جدید، نظرسنجی)
User Stories — Placeholder برای گفتگو
Bugs/Defects — مشکلات ناشی از Release قبلی
Use Cases — اعمال بین Actor و سیستم
Capabilities — راه‌های مختلف دسترسی به قابلیت‌های موجود (Mobile، Web API)

⚠️ قانون طلایی که اکثر تیم‌ها نقض می‌کنند:

One Product  →  One Product Owner  →  One Product Backlog

اگر یک Backlog برای Feature، یک Backlog برای Bug، یک Backlog برای Technical Debt و کارهای تزریقی ناگهانی داشته باشید، هیچ Transparency واقعی‌ای وجود ندارد. شما نمی‌توانید بدانید واقعاً به کجا می‌روید.

بلوک مفهومی دوم — «User Story؛ از Use Case تا گفتگو»

چرا User Story به وجود آمد؟

برای درک User Story، ابتدا باید بدانید از کجا آمد و چه مشکلی را حل کرد.

قبل از User Story، تکنیک غالب برای ثبت الزامات، Use Case بود. Use Case توسط Ivar Jacobson در سال ۱۹۸۶ ابداع شد و در دههٔ ۱۹۹۰ با رواج یافتن Unified Process (UP) و UML به اوج محبوبیت رسید.

Use Case رفتار سیستم را از دید یک Actor (کاربر یا سیستم خارجی) به صورت Scenario توصیف می‌کند و مکانیزمی برای ورود به جزئیات فراهم می‌کند.

مشکل Use Case چه بود؟

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

ارزش واقعی کمی ایجاد می‌کرد
بازنویسی زیادی می‌طلبید
گفتگوی حضوری را از بین می‌برد

Use Case هرگز قرار نبود یک سند جامع و کامل باشد. قرار بود به صورت تکراری (iteratively) در حین توسعه شکل بگیرد. اما اکثر سازمان‌ها آن را به یک مستند خسته‌کننده تبدیل کردند که ارزش کمی داشت.

تولد User Story

در دههٔ ۱۹۹۰، جامعهٔ Extreme Programming (XP) در واکنش به حجم جزئیات غیرضروری Use Case، مفهوم User Story را معرفی کرد.

دو هدف اصلی User Story:

هدف	توضیح
Brevity — اجبار به اختصار	Story باید کوتاه باشد تا فضا برای تفکر باز بماند
Purposeful Ambiguity — ابهام هدفمند	ابهام عمدی، تیم را مجبور به گفتگوی حضوری می‌کند

این ابهام هدفمند، نه یک نقص، بلکه یک ویژگی طراحی‌شده است. وقتی Story کاملاً مشخص نیست، Developer ناچار است با Product Owner یا ذینفع صحبت کند. این گفتگو خودش بخشی از ارزش است.

نویسنده تفاوت Use Case و User Story را اینطور خلاصه می‌کند:

«یک User Story یک Flow از یک Use Case را توصیف می‌کند.»

یعنی User Story دانه‌بندی (Granularity) ریزتری دارد، و به جای توصیف کامل یک رفتار سیستم، فقط یک مسیر ساده از تعامل کاربر با سیستم را بیان می‌کند.

نکتهٔ انتقادی برای یک Senior Developer

خطری که بسیاری از تیم‌ها در آن می‌افتند این است که User Story را به «Use Case سبک‌تر» تبدیل می‌کنند. یعنی همان سندگرایی Use Case را با قالب User Story تکرار می‌کنند و Acceptance Criteria را به مستندات طولانی تبدیل می‌کنند. این دقیقاً همان مشکلی است که User Story برای حل آن آمده بود. قالب مهم نیست، گفتگو مهم است.

بلوک مفهومی سوم — «فرمت User Story و سه C»

فرمت استاندارد User Story

رایج‌ترین قالب نوشتن User Story این است:

As a [type of user]
I want [some goal]
So that [some reason]

به فارسی:

به عنوان [نوع کاربر]
می‌خواهم [هدف یا قابلیت]
تا اینکه [دلیل یا ارزش]

مثال عملی:

به عنوان یک مدیر فروش،
می‌خواهم بتوانم گزارش‌های ماهانه را Export کنم،
تا اینکه بتوانم آن‌ها را با تیم مدیریت ارشد به اشتراک بگذارم.

این قالب سه عنصر حیاتی را اجبار می‌کند:

چه کسی نفع می‌برد (کاربر)
چه می‌خواهد (قابلیت)
چرا (ارزش کسب‌وکاری)

قسمت «تا اینکه» (So that) مهم‌ترین بخش است، چون ارزش را نمایان می‌کند. وقتی این بخش را نمی‌توانید پر کنید، باید از خود بپرسید آیا اصلاً این Story ارزش ساختن دارد؟

سه C: قلب واقعی User Story

فریمورک سه C توسط Ron Jeffries معرفی شد و ستون فقرات مفهومی User Story است:

C اول: Card (کارت)

Story را روی یک کارت کوچک (یا معادل دیجیتالی آن) می‌نویسید. محدودیت فیزیکی کارت عمدی است. یک کارت کوچک نمی‌تواند جزئیات زیادی داشته باشد، پس شما را مجبور به اختصار می‌کند.

Card یک تعهد نیست. یک یادداشت است — یادآوری اینکه یک گفتگو باید اتفاق بیفتد.

C دوم: Conversation (گفتگو)

این مهم‌ترین C است. اکثر ارزش یک User Story نه در متن آن، بلکه در گفتگویی است که بین Product Owner، Development Team و ذینفعان اتفاق می‌افتد.

نویسنده تأکید می‌کند که User Story یک Promise for a Conversation (وعدهٔ یک گفتگو) است، نه یک مشخصهٔ کامل.

این گفتگو است که:

ابهام‌ها را برطرف می‌کند
سوءتفاهم‌ها را پیش از Coding آشکار می‌کند
درک مشترک (Shared Understanding) می‌سازد

⚠️ هشدار انتقادی: تیم‌هایی که گفتگو را حذف می‌کنند و به جای آن جزئیات بیشتری در Card می‌نویسند، دقیقاً همان اشتباه Use Case را با قالب متفاوت تکرار می‌کنند.

C سوم: Confirmation (تأیید)

چطور می‌دانید که Story به درستی پیاده‌سازی شده؟ Confirmation همان Acceptance Criteria است.

Acceptance Criteria باید:

مشخص و قابل تست باشند
از دید کاربر نوشته شوند، نه از دید سیستم
توسط Product Owner تعریف، و توسط Development Team تست شوند

یک فرمت رایج برای Acceptance Criteria، قالب Given/When/Then است:

Given [یک پیش‌شرط]
When [یک اتفاق یا عمل]
Then [نتیجهٔ مورد انتظار]

مثال:

Given کاربر وارد سیستم شده است
When روی دکمهٔ Export کلیک می‌کند
Then یک فایل CSV با داده‌های ماه جاری دانلود می‌شود

رابطهٔ سه C با Transparency در Scrum

C	نقش در Scrum
Card	آیتم در Product Backlog
Conversation	اتفاقی که در Refinement می‌افتد
Confirmation	معیار Done بودن در Sprint Review

بلوک مفهومی چهارم — «INVEST؛ معیار یک User Story خوب»

چرا به معیار نیاز داریم؟

نوشتن User Story آسان است. نوشتن یک User Story خوب نیاز به دانش دارد. بسیاری از تیم‌ها Story می‌نویسند که یا خیلی بزرگ است، یا قابل تست نیست، یا ارزش مشخصی ندارد. برای حل این مشکل، Bill Wake معیار INVEST را معرفی کرد — یک چک‌لیست شش‌گانه برای ارزیابی کیفیت یک User Story.

شش معیار INVEST

I — Independent (مستقل)

هر Story باید تا حد ممکن از Story‌های دیگر مستقل باشد.

وابستگی بین Story‌ها یعنی:

نمی‌توانید آن‌ها را به صورت جداگانه Prioritize کنید
برنامه‌ریزی Sprint دشوار می‌شود
تیم در انتخاب آزاد نیست

اگر دو Story به هم وابسته‌اند، گزینه‌های شما این است:

آن‌ها را با هم ادغام کنید
آن‌ها را بازنویسی کنید تا وابستگی حذف شود

N — Negotiable (قابل مذاکره)

Story یک قرارداد نیست، یک دعوتنامه برای گفتگو است. جزئیات Story تا زمانی که وارد Sprint نشده، باید قابل تغییر و مذاکره باشد.

این مستقیماً به C دوم (Conversation) مرتبط است. اگر Story را «سنگ» کنید و هیچ انعطافی در آن نباشد، روح Agile را از بین برده‌اید.

⚠️ این به معنای بی‌نظمی نیست. یعنی راه‌حل قابل مذاکره است، نه ارزش آن.

V — Valuable (ارزشمند)

هر Story باید ارزش مشخصی برای کاربر یا کسب‌وکار داشته باشد.

این معیار خطرناک‌ترین نقطهٔ شکست است. Story‌های فنی صرف (مثلاً «Database را به نسخهٔ جدید Migrate کن») به تنهایی ارزش کاربری ندارند. راه‌حل این است که آن‌ها را در قالب Enabler یا به عنوان بخشی از یک Story ارزشمندتر تعریف کنید، نه به صورت مستقل.

قانون ساده: اگر نمی‌توانید «So that» را پر کنید، Story ارزشمند نیست.

E — Estimable (قابل تخمین)

Development Team باید بتواند اندازهٔ Story را تخمین بزند.

اگر نمی‌توان تخمین زد، معمولاً یکی از این سه مشکل وجود دارد:

مشکل	راه‌حل
Story خیلی بزرگ است	آن را به Story‌های کوچکتر تقسیم کنید
تیم دانش فنی کافی ندارد	یک Spike (تحقیق فنی) به Backlog اضافه کنید
Story خیلی مبهم است	گفتگوی بیشتری با Product Owner نیاز است

S — Small (کوچک)

یک Story باید آنقدر کوچک باشد که در یک Sprint قابل تکمیل باشد — ترجیحاً در چند روز.

Story‌های بزرگ را Epic می‌نامند. Epic‌ها در بالای Product Backlog نباید وجود داشته باشند. هرچه Story به Sprint نزدیک‌تر می‌شود، باید شکسته‌تر و شفاف‌تر شده باشد.

این مستقیماً با مفهوم Progressive Refinement در Scrum مرتبط است: Story‌های دور با جزئیات کم، Story‌های نزدیک با جزئیات کامل.

T — Testable (قابل تست)

Story باید Acceptance Criteria داشته باشد که بتوان آن را به صورت عینی تست کرد.

اگر نمی‌توان تست نوشت، یعنی Story هنوز به اندازهٔ کافی شفاف نیست. این معیار مستقیماً به C سوم (Confirmation) از مدل قبلی متصل است.

INVEST در یک نگاه

I → Independent   مستقل از سایر Story‌ها
N → Negotiable    جزئیات آن قابل مذاکره است
V → Valuable      ارزش کاربری یا تجاری دارد
E → Estimable     قابل تخمین توسط تیم است
S → Small         در یک Sprint قابل تکمیل است
T → Testable      Acceptance Criteria دارد

نکتهٔ انتقادی

INVEST یک ابزار تشخیص است، نه یک فرمول جادویی. در دنیای واقعی، همیشه نمی‌توانید هر شش معیار را به طور کامل برآورده کنید. اما هر بار که یکی از این معیارها نقض می‌شود، یک ریسک وارد Sprint شما شده که باید آگاهانه مدیریت شود.

Product Backlog Refinement (که قبلاً Grooming هم نامیده می‌شد) فرآیندی مستمر است که در آن Product Owner و Development Team با هم روی Product Backlog کار می‌کنند تا:

آیتم‌های بالای Backlog را شفاف‌تر کنند
آن‌ها را تخمین بزنند
Epic‌های بزرگ را به Story‌های کوچک‌تر بشکنند

از Scrum Guide:

«Product Backlog Refinement عملی است که در آن جزئیات، ترتیب و اندازهٔ Product Backlog Item‌ها بازبینی می‌شوند. این یک فعالیت مستمر است، نه یک رویداد رسمی.»

Scrum، یک زمان ثابت برای Refinement تعریف نمی‌کند. اما قانون کلی این است که Development Team نباید بیش از ۱۰٪ از ظرفیت Sprint را صرف Refinement کند.

در عمل، اکثر تیم‌های موفق یک یا دو جلسهٔ منظم Refinement در هر Sprint دارند، معمولاً در اواسط Sprint — زمانی که تیم هنوز روی Sprint جاری کار می‌کند اما باید برای Sprint بعدی آماده شود.

DEEP؛ ویژگی‌های یک Product Backlog سالم

Mike Cohn چهار ویژگی برای یک Product Backlog ایده‌آل تعریف کرده که با مخفف DEEP شناخته می‌شود:

D — Detailed Appropriately (جزئیات متناسب)

آیتم‌های بالای Backlog باید جزئیات بیشتری داشته باشند، چون به زودی وارد Sprint می‌شوند. آیتم‌های پایین‌تر می‌توانند مبهم‌تر و کلی‌تر باشند.

این یک اشتباه رایج است که تیم‌ها تلاش می‌کنند تمام آیتم‌های Backlog را با جزئیات کامل بنویسند. این کار هدر دادن انرژی است، چون آیتم‌های پایینی ممکن است ماه‌ها بعد تغییر کنند یا اصلاً حذف شوند.

بالای Backlog    →    جزئیات بالا + Acceptance Criteria کامل
وسط Backlog     →    جزئیات متوسط + توضیح کلی
پایین Backlog   →    فقط عنوان + ایده‌ٔ کلی

E — Estimated (تخمین‌زده‌شده)

آیتم‌های بالایی باید تخمین داشته باشند. تخمین به Product Owner کمک می‌کند تصمیمات بهتری بگیرد — چون ارزش بدون دانستن هزینه، بی‌معناست.

نکتهٔ مهم: طبق Scrum Guide، تخمین حق انحصاری Development Team است. Product Owner می‌تواند زمینه و ارزش را توضیح دهد و Trade-off ها را مطرح کند، اما هرگز نمی‌تواند تخمین را تحمیل کند.

E — Emergent (در حال ظهور)

Product Backlog هرگز کامل نمی‌شود. همیشه در حال تغییر و تکامل است.

نیازهای بازار تغییر می‌کنند، رقبا حرکت می‌کنند، کاربران بازخورد می‌دهند. یک Product Owner که فکر می‌کند می‌تواند یک Backlog «نهایی» داشته باشد، دچار توهم برنامه‌ریزی Waterfall شده است.

P — Prioritized (اولویت‌بندی‌شده)

آیتم‌هایی که بیشترین ارزش دارند باید بالای Backlog باشند. اولویت‌بندی وظیفهٔ انحصاری Product Owner است و باید بر اساس ارزش کسب‌وکاری باشد، نه فشار تیم‌های داخلی یا ذینفعان声‌بلند.

Definition of Ready؛ آیا Story آمادهٔ Sprint است؟

برخی تیم‌ها یک Definition of Ready (DoR) تعریف می‌کنند — معیاری که مشخص می‌کند یک Story چه زمانی آنقدر شفاف است که می‌توان آن را در Sprint Planning انتخاب کرد.

یک DoR معمولی ممکن است شامل این موارد باشد:

Story با فرمت استاندارد نوشته شده
Acceptance Criteria مشخص و قابل تست دارد
تخمین توسط Development Team انجام شده
وابستگی‌های خارجی شناسایی و مدیریت شده
در حد یک Sprint قابل تکمیل است (INVEST رعایت شده)

هشدار مهم دربارهٔ Definition of Ready

نویسنده یک خطر جدی را گوشزد می‌کند:

اگر Development Team هیچ Story‌ای را بدون DoR کامل وارد Sprint نکند، ممکن است این تبدیل به یک دیوار بوروکراتیک شود که جریان ارزش را کند می‌کند.

DoR باید یک راهنما باشد، نه یک دروازهٔ سخت. انعطاف لازم است. گاهی یک Story با کمی ابهام وارد Sprint می‌شود و تیم در حین کار جزئیات را کشف می‌کند — این کاملاً طبیعی است.

Product Backlog  ←  Refinement آن را آماده می‌کند
      ↓
Sprint Backlog   ←  از بالای Product Backlog تغذیه می‌شود
      ↓
Increment        ←  نتیجهٔ کار روی Sprint Backlog است

بلوک مفهومی ششم — «Story Splitting؛ شکستن Epic به Story‌های قابل تحویل»

چرا شکستن Story اهمیت دارد؟

یکی از رایج‌ترین مشکلاتی که تیم‌های Scrum با آن دست‌وپنجه نرم می‌کنند این است که Story‌هایی دارند که آنقدر بزرگند که در یک Sprint جا نمی‌شوند. این Story‌های بزرگ را Epic می‌نامیم.

Epic به خودی خود مشکلی ندارد — در پایین Backlog جای طبیعی دارد. مشکل زمانی است که یک Epic بدون شکسته شدن وارد Sprint می‌شود و در انتهای Sprint ناتمام می‌ماند. این دقیقاً همان چیزی است که Transparency را نابود می‌کند، چون Increment واقعی‌ای تحویل نمی‌دهید.

الگوهای رایج Story Splitting

نویسنده چندین الگو برای شکستن Story معرفی می‌کند. مهم است بدانید که هر Story را می‌توان به روش‌های متفاوتی شکست و انتخاب الگو بستگی به ماهیت Story دارد.

۱. شکستن بر اساس Workflow Steps (مراحل گردش کار)

اگر یک Story شامل چند مرحلهٔ متوالی است، هر مرحله می‌تواند یک Story مستقل شود.

مثال:

Epic: کاربر می‌تواند محصول بخرد

→ Story 1: کاربر می‌تواند محصول را به سبد خرید اضافه کند
→ Story 2: کاربر می‌تواند اطلاعات پرداخت را وارد کند
→ Story 3: کاربر می‌تواند سفارش را تأیید و نهایی کند

۲. شکستن بر اساس Business Rule Variations (تنوع قوانین کسب‌وکار)

گاهی یک قابلیت برای حالت‌های مختلف قوانین متفاوتی دارد. ساده‌ترین حالت را اول بسازید.

مثال:

Epic: سیستم تخفیف برای کاربران

→ Story 1: تخفیف ثابت ۱۰٪ برای همهٔ کاربران
→ Story 2: تخفیف متغیر بر اساس سطح عضویت
→ Story 3: تخفیف ترکیبی با کد تخفیف

۳. شکستن بر اساس Happy Path vs. Edge Cases

ابتدا Happy Path (مسیر اصلی و موفق) را بسازید، سپس Edge Case‌ها را.

→ Story 1: کاربر با موفقیت Login می‌کند (Happy Path)
→ Story 2: رمز عبور اشتباه — پیام خطای مناسب نمایش داده می‌شود
→ Story 3: حساب قفل شده پس از ۵ تلاش ناموفق

این الگو بسیار قدرتمند است چون تیم را مجبور می‌کند اول چیزی که واقعاً کار می‌کند را تحویل دهد.

۴. شکستن بر اساس Data Variations (تنوع داده)

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

Epic: آپلود فایل

→ Story 1: آپلود فایل PDF
→ Story 2: آپلود تصویر (JPG, PNG)
→ Story 3: آپلود فایل Excel

۵. شکستن بر اساس Interface Channel (کانال دسترسی)

اگر یک قابلیت از چند کانال مختلف باید در دسترس باشد:

Epic: گزارش‌گیری

→ Story 1: گزارش در رابط وب
→ Story 2: گزارش در اپلیکیشن موبایل
→ Story 3: ارسال خودکار گزارش از طریق ایمیل

اشتباه رایج: شکستن به صورت فنی (Horizontal Splitting)

بسیاری از تیم‌های توسعه‌ٔ نرم‌افزار وسوسه می‌شوند که Story را به لایه‌های فنی تقسیم کنند:

❌ اشتباه:
→ Story 1: طراحی Database Schema
→ Story 2: پیاده‌سازی API
→ Story 3: طراحی UI

این روش — که Horizontal Splitting نام دارد — کاملاً غلط است. چرا؟

چون در پایان هر Story، هیچ Increment قابل تحویل به کاربر وجود ندارد. یک Schema بدون API و UI هیچ ارزش کاربری ندارد.

شکستن درست باید عمودی (Vertical) باشد — یعنی هر Story از UI تا Database را دربر بگیرد و یک قابلیت کوچک اما کامل تحویل دهد.

✅ درست (Vertical Slice):
→ Story: کاربر می‌تواند نام خود را در پروفایل ویرایش و ذخیره کند
   (شامل UI + API + Database در یک Story)

رابطهٔ Story Splitting با Definition of Done

هر Story‌ای که از Epic شکسته می‌شود، باید همان Definition of Done کل محصول را رعایت کند. این نکتهٔ مهمی است که تیم‌ها نادیده می‌گیرند.

نباید برای Story‌های کوچک‌تر DoD را «سبک‌تر» کنید، چون این کار Technical Debt ایجاد می‌کند و در آینده هزینهٔ سنگینی می‌پردازید.

خلاصهٔ عملی Story Splitting

Epic بزرگ در Backlog
        ↓
شناسایی الگوی مناسب برای شکستن
        ↓
Vertical Slice — هر Story از UI تا DB
        ↓
بررسی INVEST برای هر Story
        ↓
Story آمادهٔ Refinement و تخمین

بلوک مفهومی هفتم — «Estimation؛ تخمین نسبی و Story Points»

چرا تخمین به ساعت شکست می‌خورد؟

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

چرا؟ چون تخمین به ساعت دو فرض غلط دارد:

همهٔ اعضای تیم سرعت یکسانی دارند
پیچیدگی یک کار با مدت زمان آن رابطهٔ خطی دارد

هر دو فرض در دنیای واقعی نادرستند.

تخمین نسبی — Relative Estimation

راه‌حل، جایگزین کردن تخمین مطلق (ساعت/روز) با تخمین نسبی است.

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

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

Story Points

Story Point واحد اندازه‌گیری نسبی است که سه بُعد را با هم در نظر می‌گیرد:

Story Point  =  Complexity (پیچیدگی)
             +  Effort (میزان کار)
             +  Uncertainty (عدم قطعیت)

Story Point یک واحد انتزاعی است — عدد ۵ به تنهایی معنی ندارد. ارزش آن در مقایسه است: یک Story با ۵ امتیاز دو برابر یک Story با ۲.۵ امتیاز کار دارد.

نکتهٔ مهم طبق Scrum Guide:

تخمین حق انحصاری Development Team است. Product Owner می‌تواند زمینه و ارزش را توضیح دهد، اما هرگز نمی‌تواند تخمین را تحمیل کند یا تغییر دهد.

این یک مرز کاملاً مشخص است که نباید نقض شود.

Planning Poker — ابزار تخمین گروهی

رایج‌ترین تکنیک برای تخمین Story Points، Planning Poker است.

فرآیند آن به این صورت است:

Product Owner یک Story را می‌خواند و توضیح می‌دهد
تیم سؤال می‌کند تا ابهام‌ها برطرف شود
هر عضو تیم به صورت مخفیانه یک عدد از دنبالهٔ Fibonacci انتخاب می‌کند
همه با هم کارت‌ها را رو می‌کنند
اگر اختلاف وجود دارد، بالاترین و پایین‌ترین تخمین توضیح می‌دهند
گفتگو ادامه می‌یابد تا به توافق برسند

چرا از دنبالهٔ Fibonacci استفاده می‌شود؟

اعداد Fibonacci که در Planning Poker استفاده می‌شوند معمولاً این‌ها هستند:

1 — 2 — 3 — 5 — 8 — 13 — 21 — ?

دلیل استفاده از این دنباله هوشمندانه است: هرچه Story بزرگ‌تر می‌شود، فاصلهٔ بین اعداد هم بزرگ‌تر می‌شود. این به صورت ضمنی می‌گوید که تخمین Story‌های بزرگ ذاتاً نادقیق است و نباید وانمود کنیم که می‌توانیم بین ۱۴ و ۱۵ تفاوت قائل شویم.

علامت ؟ هم در برخی دسته‌های کارت وجود دارد — یعنی «این Story آنقدر مبهم است که نمی‌توانم تخمین بزنم» — که سیگنال مهمی برای نیاز به Refinement بیشتر است.

Velocity — سرعت تیم

پس از چند Sprint، الگویی از عملکرد تیم شکل می‌گیرد. مجموع Story Points تکمیل‌شده در هر Sprint، Velocity تیم نامیده می‌شود.

Velocity ابزاری است برای پیش‌بینی، نه ارزیابی عملکرد.

⚠️ یک هشدار جدی از کتاب:

Velocity معیار ارزش تحویل‌داده‌شده نیست. تیمی که Velocity بالایی دارد اما Story‌های اشتباه می‌سازد، ارزشی ایجاد نکرده است.

استفادهٔ غلط از Velocity — مثل فشار آوردن به تیم برای افزایش آن — دقیقاً همان چیزی است که Goodhart’s Law توصیف می‌کند:

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

تیم‌ها شروع می‌کنند به Inflation کردن تخمین‌ها یا انتخاب Story‌های آسان‌تر تا Velocity بالاتر به نظر برسد. این رفتار Backfire است.

رابطهٔ Estimation با Product Backlog Ordering

تخمین به Product Owner این امکان را می‌دهد که تصمیمات آگاهانه‌تری بگیرد. فرمول ذهنی ساده است:

اولویت  =  Value (ارزش)  ÷  Effort (تخمین)

یک Story با ارزش متوسط اما تخمین خیلی پایین، ممکن است ROI بهتری نسبت به یک Story با ارزش بالا اما تخمین بسیار بالا داشته باشد. این همان Cost of Delay thinking است که Product Owner باید در Ordering از آن استفاده کند.

بلوک مفهومی هشتم — «Definition of Done؛ مرز واقعی تمام‌شدن کار»

مشکل بدون DoD

یکی از مخرب‌ترین پدیده‌هایی که در تیم‌های Scrum اتفاق می‌افتد، مفهومی است که به آن Undone Work گفته می‌شود. کاری که «تقریباً تمام شده» — کدش نوشته شده، اما تست نشده. یا تست شده، اما Deploy نشده. یا Deploy شده اما مستند نشده.

این «تقریباً تمام» در واقعیت یعنی تمام نشده. و انباشت این کارهای ناتمام، همان Technical Debt است که به آرامی سرعت تیم را نابود می‌کند.

Definition of Done (DoD) دقیقاً برای حل این مشکل وجود دارد.

تعریف رسمی از Scrum Guide

«وقتی یک Product Backlog Item یا Increment به عنوان Done توصیف می‌شود، همه باید بدانند Done به چه معناست. اگرچه این ممکن است بین Scrum Team‌ها متفاوت باشد، اعضا باید درک مشترکی از معنای کامل بودن کار داشته باشند تا Transparency تضمین شود.»

DoD یک قرارداد مشترک است — نه بین Product Owner و مشتری، بلکه بین تمام اعضای Scrum Team با خودشان.

DoD در مقابل Acceptance Criteria

این دو مفهوم اغلب با هم اشتباه گرفته می‌شوند. تفاوت اساسی این است:

	Definition of Done	Acceptance Criteria
سطح	کل محصول و تیم	یک Story خاص
تعریف‌کننده	Scrum Team	Product Owner
تغییر	به ندرت تغییر می‌کند	برای هر Story متفاوت است
هدف	تضمین کیفیت فنی	تضمین درستی عملکرد

یک Story می‌تواند تمام Acceptance Criteria خود را Pass کند اما هنوز Done نباشد — اگر DoD رعایت نشده باشد. مثلاً اگر DoD شامل Code Review است و آن Story هنوز Review نشده، Done نیست.

اجزای یک DoD واقعی

DoD هر تیم منحصربه‌فرد است، اما یک DoD بالغ معمولاً این موارد را پوشش می‌دهد:

سطح کد:

کد نوشته و Commit شده
Code Review توسط حداقل یک نفر دیگر انجام شده
Coding Standards رعایت شده

سطح تست:

Unit Tests نوشته و Pass شده
Integration Tests Pass شده
Acceptance Tests بر اساس Criteria تأیید شده
Regression Tests اجرا شده

سطح استقرار:

به محیط Staging یا Production Deploy شده
در محیط واقعی تأیید شده

سطح مستندات:

مستندات فنی به‌روز شده
Release Notes در صورت نیاز نوشته شده

DoD باید در طول زمان رشد کند

از Scrum Guide:

«با بلوغ Scrum Teams، انتظار می‌رود که Definition of Done آن‌ها گسترش یابد تا معیارهای سخت‌گیرانه‌تری برای کیفیت بالاتر داشته باشد.»

این یعنی DoD یک سند زنده است. در Sprint Retrospective، تیم باید از خود بپرسد:

آیا چیزی هست که باید به DoD اضافه کنیم؟
آیا DoD فعلی در عمل رعایت می‌شود؟
آیا Undone Work داریم که نشانهٔ ضعف در DoD است؟

نقش Product Owner در DoD

نویسنده تأکید می‌کند که Product Owner نمی‌تواند نسبت به DoD بی‌تفاوت باشد:

«اگر Product Backlog مسیر شماست و Increment قطب‌نمای شما، آنگاه Done میدان مغناطیسی است که سوزن قطب‌نما را به حرکت درمی‌آورد. بدون آن، نه موقعیتی دارید و نه می‌توانید مسیر را تنظیم کنید.»

Product Owner باید در Sprint Review تنها Increment‌هایی را بپذیرد که واقعاً Done هستند. پذیرفتن کار ناتمام — حتی با نیت خوب برای «بعداً تکمیل کردن» — چرخهٔ Transparency را می‌شکند.

Undone Work؛ بدهی پنهانی که سود مرکب دارد

هر Sprint که با Undone Work تمام می‌شود، این بدهی به Sprint بعدی منتقل می‌شود. اما این بدهی مثل بدهی مالی بهره دارد:

Sprint 1:  ۱۰ Story Point کار ناتمام
Sprint 2:  همان ۱۰ + ۵ اضافه از وابستگی‌های جدید = ۱۵
Sprint 3:  ۱۵ + هزینهٔ Context Switch + Bug ناشی از آن = ۲۵+

این همان چیزی است که Steve McConnell به زیبایی توصیف می‌کند:

«مشکل Quick and Dirty این است که Dirty خیلی وقت بعد از اینکه Quick فراموش شد، باقی می‌ماند.»

نکتهٔ انتقادی برای یک Senior Developer

یک اشتباه رایج این است که DoD را برای «آرام کردن» فشار Release سبک می‌کنند. مثلاً وقتی Deadline نزدیک است، تیم تصمیم می‌گیرد «این بار» Code Review را حذف کنند یا Integration Test را Skip کنند.

این تصمیم در لحظه کوچک به نظر می‌رسد اما اثر ترکیبی آن مخرب است. هر بار که DoD نقض می‌شود، استاندارد کیفیت تیم یک پله پایین می‌آید. و تیمی که یک بار این کار را کرد، دفعهٔ بعد راحت‌تر آن را تکرار می‌کند.

راه‌حل این نیست که DoD را نقض کنید — راه‌حل این است که Scope را کاهش دهید و با Story کمتر اما Done واقعی Sprint را تمام کنید.

بلوک مفهومی نهم — «Ordering؛ هنر اولویت‌بندی Product Backlog»

تفاوت Ordering با Prioritization

نویسنده از ابتدا یک تمایز مهم زبانی مطرح می‌کند: در Scrum از کلمهٔ Ordering (مرتب‌سازی) استفاده می‌شود، نه Prioritization (اولویت‌بندی).

چرا؟ چون Prioritization تداعی‌گر دسته‌بندی به سطوح است — مثلاً High، Medium، Low — که در عمل به این منجر می‌شود که همه چیز «High» می‌شود و هیچ تصمیم سختی گرفته نمی‌شود.

Ordering اما یک لیست کاملاً خطی است. آیتم شمارهٔ ۱ مهم‌تر از شمارهٔ ۲ است و شمارهٔ ۲ مهم‌تر از شمارهٔ ۳ — بدون استثنا. این تصمیمات سخت را اجباری می‌کند.

Ordering وظیفهٔ انحصاری Product Owner است. هیچ‌کس دیگری این حق را ندارد.

عواملی که Ordering را تعیین می‌کنند

Ordering یک تصمیم چندبُعدی است. Product Owner باید همزمان چندین عامل را در نظر بگیرد:

۱. ارزش کسب‌وکاری (Business Value)

پایه‌ای‌ترین عامل. چه آیتمی بیشترین ارزش را برای کاربر یا کسب‌وکار ایجاد می‌کند؟

اما نویسنده هشدار می‌دهد که ارزش به تنهایی کافی نیست. یک Story با ارزش بالا اما تخمین بسیار زیاد، ممکن است ROI کمتری نسبت به یک Story با ارزش متوسط و تخمین پایین داشته باشد.

فرمول ذهنی:

اولویت واقعی  ≈  Value ÷ Effort

۲. Cost of Delay (هزینهٔ تأخیر)

این مفهوم از Don Reinertsen است و یکی از قدرتمندترین ابزارهای تفکر برای Product Owner:

«اگر این Feature را یک ماه دیرتر تحویل دهیم، چه اتفاقی می‌افتد؟»

برخی Feature‌ها هزینهٔ تأخیر بالایی دارند — مثلاً یک قابلیت رقابتی که اگر رقیب زودتر آن را Release کند، بازار را از دست می‌دهید. برخی دیگر هزینهٔ تأخیر پایینی دارند.

Cost of Delay اغلب مشخص می‌کند که کدام آیتم باید همین الان ساخته شود.

۳. Risk Reduction (کاهش ریسک)

گاهی یک آیتم از نظر ارزش فوری زیاد نیست، اما اگر زودتر ساخته شود، ریسک بزرگی را از پروژه حذف می‌کند.

مثلاً یک Proof of Concept فنی که ثابت می‌کند معماری انتخاب‌شده جواب می‌دهد — اگر دیر انجام شود و معماری اشتباه باشد، ماه‌ها کار هدر می‌رود.

۴. Dependencies (وابستگی‌ها)

برخی آیتم‌ها Enabler هستند — یعنی تا آن‌ها ساخته نشوند، آیتم‌های دیگر قابل توسعه نیستند. این وابستگی‌ها باید در Ordering لحاظ شوند، حتی اگر ارزش مستقیم آن Enabler کم باشد.

مدل Kano؛ ابزار تحلیل ارزش

یکی از ابزارهای مفیدی که نویسنده به آن اشاره می‌کند، مدل Kano است که توسط Noriaki Kano در سال ۱۹۸۴ معرفی شد. این مدل Feature‌ها را به سه دسته تقسیم می‌کند:

دسته	توضیح	مثال
Basic Needs (Must-Be)	انتظار پایه‌ای کاربر — نبودشان نارضایتی شدید ایجاد می‌کند، بودنشان Neutral است	امنیت در یک اپ بانکی
Performance Needs	هرچه بیشتر باشند، رضایت بیشتر — رابطهٔ خطی با رضایت کاربر	سرعت بارگذاری صفحه
Delighters (Excitement)	کاربر انتظارشان را ندارد اما وقتی می‌بیند هیجان‌زده می‌شود	یک Feature خلاقانه و غیرمنتظره

نکتهٔ مهم Kano: Delighter‌های امروز، Basic Needs فردا هستند. وقتی یک Feature هیجان‌انگیز رایج می‌شود، کاربران آن را당ر می‌گیرند و نبودش نارضایتی ایجاد می‌کند.

این مدل به Product Owner کمک می‌کند درک کند چرا بعضی Feature‌ها با وجود سرمایه‌گذاری زیاد، رضایت کاربر را افزایش نمی‌دهند — چون Basic Need هستند و کاربر آن‌ها را بدیهی می‌داند.

اشتباهات رایج در Ordering

اشتباه اول: Ordering بر اساس فشار صدای بلندترین ذینفع

ذینفعی که بیشترین سروصدا را دارد لزوماً مهم‌ترین نیاز را ندارد. Product Owner باید بر اساس داده و استراتژی تصمیم بگیرد، نه فشار سیاسی.

اشتباه دوم: Feature Factory شدن

وقتی Product Owner فقط بر اساس Feature Request های ورودی Ordering می‌کند، بدون ارزیابی Outcome واقعی، محصول به یک کارخانهٔ Feature تبدیل می‌شود که زیاد می‌سازد اما ارزش واقعی کمی ایجاد می‌کند.

اشتباه سوم: ثابت نگه داشتن Ordering

Ordering یک تصمیم لحظه‌ای است. بازار تغییر می‌کند، رقبا حرکت می‌کنند، کاربران بازخورد می‌دهند. Product Owner باید حاضر باشد Ordering را — حتی در آستانهٔ Sprint Planning — بر اساس اطلاعات جدید تغییر دهد.

Ordering و Sprint Goal

یک نکتهٔ ظریف اما مهم: آیتم‌های بالای Backlog باید نه فقط با هم مرتب بلکه با هم هماهنگ هم باشند تا بتوان از آن‌ها یک Sprint Goal منسجم ساخت.

اگر سه آیتم بالای Backlog کاملاً بی‌ربط به هم باشند، Sprint Goal معناداری نخواهید داشت و تیم Focus لازم را از دست می‌دهد. این یعنی Ordering باید نه فقط به صورت آیتم‌به‌آیتم، بلکه با نگاه به گروه‌های منسجم انجام شود.

بلوک مفهومی دهم — «Quiz Review فصل ۷ و جمع‌بندی نهایی»

مرور Quiz ابتدای فصل

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

گزاره ۱: «Product Backlog جایگزین نیاز به هر سند الزاماتی می‌شود»

✅ موافق — اما با یک شرط

Product Backlog تنها منبع کار برای Development Team است. اما این به معنای نفی هر نوع مستندسازی نیست. در برخی دامنه‌ها مثل پزشکی، هوافضا یا قراردادهای قیمت‌ثابت، مستندات تکمیلی ممکن است ارزش قانونی یا ایمنی داشته باشند. قانون اصلی این است: یک Product Backlog، نه چند Backlog موازی.

گزاره ۲: «الزامات Agile باید بیش از چند جمله نباشند»

❌ مخالف

این یک سوءتفاهم رایج است. طول Story مهم نیست — کیفیت گفتگویی که ایجاد می‌کند مهم است. یک Story می‌تواند چند جمله باشد یا Acceptance Criteria مفصلی داشته باشد. معیار واقعی، INVEST است نه طول متن.

گزاره ۳: «User Story مترادف با Product Backlog Item است»

❌ مخالف

User Story یکی از انواع Product Backlog Item است، نه معادل آن. همان‌طور که در فصل دیدیم، Backlog می‌تواند شامل Bug، Experiment، Capability، Use Case و Nonfunctional Requirement هم باشد.

گزاره ۴: «Defect‌ها نباید در Product Backlog باشند چون Development Team آن‌ها را Triage می‌کند»

❌ مخالف

تمام کار — از جمله Bug‌ها — باید در یک Product Backlog باشد. این قانون طلایی «One Product, One Product Owner, One Product Backlog» است. داشتن یک Bug Backlog جداگانه Transparency را نابود می‌کند و Product Owner کنترل واقعی اولویت‌بندی را از دست می‌دهد.

گزاره ۵: «Development Team نباید هیچ Story‌ای را وارد Sprint کند مگر اینکه Definition of Ready کامل داشته باشد»

❌ مخالف — با دقت

Definition of Ready یک راهنماست، نه یک دروازهٔ سخت بوروکراتیک. اگر DoR به یک مانع برای جریان ارزش تبدیل شود، روح Agile نقض شده. گاهی یک Story با کمی ابهام وارد Sprint می‌شود و تیم جزئیات را در حین کار کشف می‌کند.

گزاره ۶: «یک Product Backlog می‌تواند فقط از Test‌ها تشکیل شده باشد»

✅ موافق

این یک نکتهٔ ظریف اما مهم است. آزمایش‌ها و Experiment‌ها — مثل A/B Test یا یک نظرسنجی از کاربران — می‌توانند آیتم‌های معتبری در Product Backlog باشند. در فصل ۴ (Validation) دیدیم که حتی یک Survey ساده می‌تواند یک Release ارزشمند باشد.

نقشهٔ ذهنی فصل ۷ — یک نگاه کلی

Product Backlog Management
│
├── الزام چیست؟
│     ├── Functional
│     ├── Nonfunctional
│     └── Business Rules
│
├── انواع آیتم‌های Backlog
│     ├── User Story (رایج‌ترین)
│     ├── Bug / Defect
│     ├── Experiment
│     ├── Nonfunctional Requirement
│     └── Capability
│
├── User Story
│     ├── فرمت: As a / I want / So that
│     ├── سه C: Card → Conversation → Confirmation
│     └── INVEST: Independent, Negotiable, Valuable,
│                 Estimable, Small, Testable
│
├── Refinement
│     ├── فرآیند مستمر (نه یک رویداد رسمی)
│     ├── حداکثر ۱۰٪ ظرفیت Sprint
│     └── DEEP: Detailed, Estimated, Emergent, Prioritized
│
├── Story Splitting
│     ├── Vertical Slice (درست)
│     └── Horizontal Split (غلط)
│
├── Estimation
│     ├── Relative > Absolute
│     ├── Story Points: Complexity + Effort + Uncertainty
│     ├── Planning Poker + Fibonacci
│     └── Velocity: ابزار پیش‌بینی، نه ارزیابی
│
├── Definition of Done
│     ├── قرارداد مشترک تیم
│     ├── با DoD رشد می‌کند
│     └── نقض DoD = Technical Debt با سود مرکب
│
└── Ordering
      ├── خطی و انحصاری Product Owner
      ├── Value ÷ Effort
      ├── Cost of Delay
      ├── Risk Reduction
      ├── مدل Kano
      └── هماهنگی با Sprint Goal

یک درس نهایی از فصل ۷

نویسنده در کل این فصل یک پیام محوری دارد که به شکل‌های مختلف تکرار می‌کند:

Product Backlog یک لیست کار نیست. یک ابزار تفکر، ارتباط و تصمیم‌گیری است.

تفاوت یک Product Owner معمولی با یک Product Owner حرفه‌ای دقیقاً اینجاست: اولی Backlog را مدیریت می‌کند، دومی از Backlog برای هدایت محصول استفاده می‌کند.

فصل ۸ — بخش اول: تله‌ی Water-Scrum-Fall

ضد-الگویی که همه می‌شناسند اما نمی‌بینند

بسیاری از تیم‌ها تصور می‌کنند که رویکردی چابک دارند، زیرا از اصطلاحاتی مثل Sprint استفاده می‌کنند. اما نویسندگان در این فصل یک تمایز بسیار دقیق ایجاد می‌کنند.

در رویکرد توسعه‌ی سنتی (آبشاری)، فازها به‌صورت کاملاً متوالی اجرا می‌شوند: Plan → Analysis → Design → Implement → Test → Release

در نهایت تنها یک Release بزرگ در انتها انجام می‌شود. این الگو (Figure 8-2) به معنای تأخیر در ارائه‌ی ارزش است.

Water-Scrum-Fall: وقتی آبشار، لباس اسکرام می‌پوشد

برخی تیم‌ها فازهای فنی را در قالب iteration گروه‌بندی می‌کنند — حتی ممکن است نام‌هایی مثل «Analysis Sprint» یا «Design Sprint» به آنها بدهند. سپس با یک فرآیند برنامه‌ریزی و تأیید از پیش تعریف‌شده، از Scrum برای پیاده‌سازی نیازمندی‌های ثابت استفاده می‌کنند و در نهایت یک مرحله‌ی تست قبل از Release وجود دارد.

این چیزی جز Waterfall با چند practice از Scrum نیست — نویسندگان این آنتی‌پترن را Water-Scrum-Fall (Figure 8-3) می‌نامند.

نکته‌ی کلیدی برای Senior Developer: تفاوت اساسی اینجاست — در Scrum واقعی، در پایان هر Sprint یک Increment به‌اصطلاح “potentially releasable” دارید. اما اگر آن Increment را تا ماه‌ها بعد نگه دارید و Release نکنید، هنوز هم ریسک ساختن محصول اشتباه را از بین نبرده‌اید.

داستان: محصولی که ۷ ماه دیر Release شد

نویسنده از یک تجربه‌ی واقعی می‌گوید: تیم پس از ۱ سال کار روی یک محصول چاپ آنلاین، پس از ۵ ماه توانایی آپلود فایل و تنظیمات پایه‌ی چاپ را داشت. مدیریت اجازه‌ی Release زودهنگام نداد چون “هنوز تمام نشده بود.”

پس از ۷ ماه دیگر و Release نهایی، مشخص شد که اکثر مشتریان از گزینه‌های پیچیده‌ای که با دردسر زیاد اضافه شده بود استفاده نمی‌کنند. آنچه واقعاً می‌خواستند: پوسترها و بنرهای با ابعاد غیراستاندارد بود — چیزی که از طریق یک فیلد ساده‌ی “Special Instructions” کشف شد.

MVP ایده‌آل یک آپلود ساده با گزینه‌های حداقلی و همان فیلد متنی بود — نه ۱۲ ماه توسعه.

موانع Release — چرا تیم‌ها Release نمی‌کنند؟

نویسندگان یک سؤال استراتژیک مطرح می‌کنند: “چه چیزی تیم را از Release کردن باز می‌دارد؟” و پاسخ‌های احتمالی را بررسی می‌کنند:

فناوری؟ → در Test Automation، Continuous Integration و Virtualization سرمایه‌گذاری کنید
فرآیندهای داخلی؟ → فرآیندها را برای رسیدن سریع‌تر به “Done” ساده‌سازی کنید
Compliance؟ → افراد مربوط به Governance را به عنوان Stakeholder واقعی وارد کنید و Compliance را درون هر Sprint بگنجانید
Customer Absorption؟ → دریافت Release را برای مشتری ساده‌تر کنید — گاهی با یک راه‌حل فنی، گاهی با آموزش بهتر

یک هشدار مهم نویسندگان: اگر مشتری از Release می‌ترسد، دلیل احتمالی این است که Release‌های بزرگ قبلی بسیار دردناک بوده‌اند. راه‌حل فرار از درد نیست — باید آن ماهیچه را آنقدر تمرین داد تا دیگر درد نکند.

فصل ۸ — بخش دوم: هزینه‌ی Release و پیش‌بینی‌پذیری

Release: همیشه بد نیست، اما باید توجیه داشته باشد

نویسنده از یک تجربه‌ی واقعی در یک شرکت علوم زیستی (Life-science) مثال می‌زند که دو نوع مشتری داشت:

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

درس کلیدی: راه‌حل یکسان برای هر دو مشتری اشتباه بود. تیم یاد گرفت که رویکرد Release را براساس نوع مشتری تنظیم کند: Major Release برای بیمارستان‌ها و Functional/Minor Release برای دانشگاه‌ها.

این یک الگوی مهم در معماری محصول است: Release Strategy باید از Business Context استخراج شود، نه از ساختار فنی تیم.

Forecasting: پیش‌بینی در فضای ابری‌شکل

نویسندگان به سراغ مفهوم Cone of Uncertainty (مخروط عدم‌قطعیت) می‌روند که ابتدا توسط Barry Boehm در مهندسی نرم‌افزار مطرح شد. این مفهوم می‌گوید هر چقدر بیشتر تحلیل کنید، پیش‌بینی‌هایتان دقیق‌تر خواهد شد.

نویسندگان با این ایده مخالف‌اند. آن‌ها تأکید می‌کنند که این رویکرد تا حد زیادی رد شده (debunked) است. تجربه نشان داده که تحلیل بیشتر در اوایل پروژه، لزوماً به پیش‌بینی دقیق‌تر منجر نمی‌شود، زیرا پیچیدگی ذاتی نرم‌افزار این سطح از قطعیت را ممکن نمی‌سازد.

در عوض، نویسندگان استفاده از Release Burn-down Chart را توصیه می‌کنند که نشان می‌دهد:

چه مقدار از Scope تاکنون انجام شده است
Velocity تیم در اسپرینت‌های گذشته چه بوده
بر اساس این داده‌ها، آیا تا Release Date برنامه‌ریزی‌شده می‌توانیم به هدف برسیم یا نه

Burn-down و سه اهرم Product Owner

وقتی Release Burn-down Chart نشان می‌دهد که Scope پروژه از زمان Release Date بیشتر است، Product Owner دقیقاً سه اهرم دارد:

تغییر تاریخ Release → آیا تأخیر قابل توجیه است؟ آیا می‌توان انتظارات Stakeholder‌ها را هم‌اکنون مدیریت کرد؟
افزایش Velocity → آیا می‌توان تیم را تقویت کرد؟ آیا اضافه کردن عضو جدید در این مرحله کمک‌کننده است یا مثل «۹ زن برای تولد یک نوزاد در یک ماه» اوضاع را بدتر می‌کند؟
تنظیم Scope (MVP) → چه قابلیت‌هایی برای این Release ضروری‌اند؟ کدام‌ها می‌توانند به Release بعدی موکول شوند؟

نکته‌ی معماری ذهنی: این سه اهرم دقیقاً همان «Iron Triangle» سنتی هستند — زمان، هزینه و محدوده — اما از دیدگاه Product Owner، اهرم سوم (Scope) قوی‌ترین و استراتژیک‌ترین ابزار است. کاهش Scope برای یک Release مشخص، هرگز شکست نیست — بلکه نشانه‌ی تصمیم‌گیری هوشمندانه با داده است.

Governance: بوروکراسی یا شفافیت؟

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

در دنیای Waterfall، نقاط Governance با Milestone‌های توسعه هماهنگ هستند. چون تا لحظه‌ی Release چیزی ساخته نشده، همه چیز فقط «کاغذبازی است» و هیچ شواهد واقعی‌ای از پیشرفت وجود ندارد. این بی‌اعتمادی خود دلیل اصلی تولد لایه‌های بیشتر Governance می‌شود.

نویسنده داستان جالبی را تعریف می‌کند: در یک شرکت خرده‌فروشی بزرگ که معمولاً چرخه‌های ۶ تا ۱۲ ماهه داشت، برای هر Release نیاز به ۱۷ امضا بود — یک بار در Sprint Planning و یک بار قبل از Release. وقتی تیم قصد داشت هر Sprint را Release کند، این فرآیند به یک گلوگاه (Bottleneck) مطلق تبدیل شد. تنها راه‌حل، آوردن گروه Governance به عنوان Stakeholder واقعی به داخل فرآیند و اصلاح رویه‌ها بود.

پیام نویسندگان صریح است: هر زمان که یک Increment «Done» و قابل Release داشته باشید، تمام اطلاعات لازم برای Govern کردن درست محصول را در اختیار دارید. کاغذبازی، Progress Report و RAG Status Report جایگزین یک محصول کارکننده نمی‌شوند.

Agile A4 Sprint Report

به عنوان یک ابزار عملی جایگزین Governance سنتی، نویسنده «Agile A4 Sprint Report» را پیشنهاد می‌دهد — یک گزارش یک‌صفحه‌ای که هر Sprint به‌روز می‌شود و شامل:

گزارش Sprint گذشته و درس‌های آموخته‌شده
Happiness Index تیم توسعه
ریسک‌های موجود با Probability و Impact
Burn-down بر روی Product Backlog
تعداد باگ‌های باز
و مهم‌تر از همه: آیا محصول «Done» است و می‌توان آن را Release کرد؟

Kickoff: شروع درست، نصف موفقیت

نویسندگان با استناد به تحقیقات Sandy Mamoli و David Mole تأکید می‌کنند که ۳۰ درصد از موفقیت یک تیم به نحوه‌ی راه‌اندازی اولیه‌ی آن بستگی دارد. Kickoff شاید مهم‌ترین عامل نباشد، اما بد بودن آن «می‌تواند تقریباً همه چیز را خراب کند».

فصل ۸ — بخش سوم: محصولات، تیم‌ها و ماتریس تصمیم‌گیری

چهار حالت ممکن در هر سازمان

نویسندگان در این بخش یک ماتریس ۲×۲ کلیدی معرفی می‌کنند که هر سازمانی با آن روبه‌روست. محورها عبارتند از:

محور Y: تعداد Development Team‌ها (یک تیم یا بیشتر از یک)
محور X: تعداد محصولات (یک محصول یا بیشتر از یک)

	یک محصول	چند محصول
چند تیم	Scaled Scrum (Nexus)	Portfolio Management
یک تیم	Scrum	تغییر Context — کاهش Focus ⚠️

هر یک از این چهار حالت یک واقعیت متفاوت ایجاد می‌کند و رویکرد Product Owner نیز باید متناسب با آن تغییر کند.

خانه خطرناک: یک تیم، چند محصول

بدترین حالت، گوشه پایین-راست ماتریس است: یک Development Team که روی چند محصول کار می‌کند. نویسندگان صراحتاً می‌گویند این یک راه‌حل زیربهینه (Suboptimal Solution) است.

وقتی یک تیم مجبور است بین محصولات مختلف جابه‌جا شود، دو آسیب اصلی رخ می‌دهد:

Context Switching: هر بار که ذهن از یک محصول به محصول دیگری می‌رود، هزینه‌ی شناختی سنگینی پرداخت می‌شود. این هزینه هم زمان‌بر است و هم کیفیت خروجی را پایین می‌آورد.
از دست رفتن Focus: تیمی که روی چند محصول موازی کار می‌کند، در هیچ‌کدام به عمق نمی‌رسد. نه Velocity واقعی دارد، نه Domain Knowledge عمیق.

نویسنده یک تجربه‌ی واقعی ذکر می‌کند: در شرکت‌های کوچک با بودجه‌ی محدود که نمی‌توانند تیم‌های جداگانه تأمین مالی کنند، گاهی یک Product Owner تمام کارها را در یک Product Backlog واحد ادغام می‌کند و هر Sprint تصمیم می‌گیرد کدام محصول اولویت دارد. این رویکرد اجباری است، نه ایده‌آل.

نکته معماری ذهنی: این دقیقاً همان بدهی سازمانی (Organizational Debt) است که در Clean Code از بدهی فنی صحبت می‌شود. وقتی ساختار تیم درست نیست، هیچ مقدار Refactoring کدی مشکل را حل نمی‌کند.

Portfolio Management: چند تیم، چند محصول

در این حالت، سازمان چندین تیم جداگانه و چندین محصول مجزا دارد. این الزاماً یک چالش Scaling نیست — صد تیم مستقل روی صد محصول مستقل می‌توانند کاملاً با Scrum معمولی کار کنند.

چالش اصلی اینجا Portfolio Management است: کدام محصولات از همه با ارزش‌ترند؟ چقدر باید به هرکدام بودجه (یعنی تیم) اختصاص دهیم؟ کدام محصول باید متوقف شود؟

نویسندگان به تعریف Johanna Rothman از Portfolio اشاره می‌کنند:

“Portfolio عبارت است از سازمان‌دهی پروژه‌ها براساس تاریخ و ارزش، که سازمان به آن‌ها متعهد است یا برنامه دارد متعهد شود.”

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

فرآیند تصمیم‌گیری در Portfolio به این شکل است: پُرارزش‌ترین محصول از Portfolio برداشته و بسته به تعداد تیم‌های اختصاص‌یافته به آن، یا وارد Scaled Scrum (Nexus) می‌شود یا وارد Scrum معمولی.

Scaling واقعی: یک محصول، چند تیم

نویسندگان تعریف دقیقی از Scaling ارائه می‌دهند که اغلب با تعریف عامیانه آن فرق دارد:

“Scaling یعنی چند Development Team روی یک محصول واحد کار می‌کنند.”

Scaling با اجرای Agile در سازمان، مدیریت Portfolio یا حل مشکل Context Switching متفاوت است. اگر چند تیم دارید که هر کدام روی محصول جداگانه‌ای کار می‌کنند، این Scaling نیست — این Portfolio است.

برای این حالت، نویسندگان فریم‌ورک‌های مختلفی را نام می‌برند: LeSS، DAD، SAFe، Scrum@Scale و Nexus. اما رویکرد آن‌ها صریح است: Nexus به دلیل وفاداری بیشتر به ارزش‌های Scrum Guide، از نظر آن‌ها قابل اعتمادتر است.

فریم‌ورک Nexus

Nexus (به معنای «ارتباط یا پیوند بین گروه‌ها») یک فریم‌ورک است که برای زمانی طراحی شده که یک Development Team تنها کافی نیست. نویسندگان چند نکته کلیدی را برای Product Ownerها در محیط Nexus برجسته می‌کنند:

یک Product Backlog واحد همچنان وجود دارد و یک Product Owner مسئول آن است — حتی اگر ۸ تیم روی آن کار کنند. اصل «Santa Claus Rule» از فصل ۱ اینجا به وضوح نمود پیدا می‌کند: تعداد تیم‌ها هر قدر هم زیاد شود، صدای واحد محصول باید از یک نفر بیاید.

تحلیل انتقادی: یکی از رایج‌ترین اشتباهات سازمانی این است که وقتی با چند تیم و چند محصول روبه‌رو می‌شوند، بلافاصله به سراغ SAFe یا LeSS می‌روند. اما کتاب به درستی تأکید می‌کند که ابتدا باید تشخیص دهید در کدام ربع از ماتریس قرار دارید — چون هر ربع یک راه‌حل متفاوت می‌طلبد.

در اینجا ادامه‌ی بخش بعدی، دقیقاً از صفحات ۲۸۴ تا ۲۹۰ کتاب:

فصل ۸ — بخش چهارم: Nexus، Portfolio و گزارش‌دهی

وقتی یک تیم روی چند محصول کار می‌کند

نویسندگان یک نکته‌ی مهم را صریح بیان می‌کنند: تلاش برای حل مشکل کمبود تیم با این راه‌حل که «در هر Sprint فقط روی یک محصول تمرکز می‌کنیم» یک راه‌حل زیربهینه است. این رویکرد تنها در یک شرط معنا دارد: اگر تیم در طول Sprint واقعاً با کار محصول دیگر مزاحمت نشود.

دان در اینجا از یک تجربه‌ی واقعی می‌گوید: با یک Product Owner در یک شرکت کوچک کار کرد که بودجه‌ی کافی برای چند تیم جداگانه نداشت. راه‌حل آن Product Owner این بود که کار همه‌ی محصولات را در یک Product Backlog واحد ادغام کند و در هر Sprint تصمیم بگیرد کدام محصول اولویت دارد. ناکارآمد بود، اما شرکت با آگاهی این هزینه را قبول کرده بود.

Portfolio Management: مدیریت چند محصول با چند تیم

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

نویسندگان به تعریف Johanna Rothman از Portfolio اشاره می‌کنند، اما با یک نقد صریح: او از «پروژه» به جای «محصول» استفاده کرده. باوجود این، روح تعریف معتبر است:

«Portfolio یعنی سازمان‌دهیِ محصولات براساس تاریخ و ارزش، که سازمان به آن‌ها متعهد است یا برنامه دارد متعهد شود.»

فرآیند مدیریت Portfolio در یک جمله خلاصه می‌شود: انتخاب کردن، اولویت‌بندی کردن، و در صورت لزوم متوقف کردن محصولات. ارزشمندترین محصول از بالای Portfolio Backlog برداشته می‌شود و بسته به تعداد تیم‌های اختصاص‌یافته، به حوزه‌ی Scrum معمولی یا Scaled Scrum (Nexus) منتقل می‌شود.

فریم‌ورک Nexus: اسکلت بیرونی Scrum در مقیاس بزرگ

تعریف Nexus از دیکشنری Merriam-Webster گرفته شده:

«پیوند یا اتصال بین گروه‌ها، اغلب در زمینه‌ی ایجاد تمرکز.»

Ken Schwaber خود Nexus را اینطور توصیف می‌کند:

«Nexus اسکلت بیرونی (Exoskeleton) Scrum در مقیاس بزرگ است.»

Nexus برای سه تا نه Development Team روی یک محصول با یک Product Owner و یک Product Backlog طراحی شده است. نکته‌ی کلیدی که نویسندگان تأکید می‌کنند این است: از دیدگاه Stakeholderها، تقسیم‌بندی کار بین Development Teamها باید نامرئی باشد. آن‌ها یک محصول یکپارچه می‌بینند، نه کار تکه‌تکه شده.

برخلاف Scrum معمولی، در Nexus رویداد Product Backlog Refinement اجباری است، زیرا چند تیم باید در یک راستا حرکت کنند. این Refinement در دو سطح اتفاق می‌افتد:

سطح کل Nexus: همه‌ی تیم‌ها با هم اقلام بالای Backlog را بررسی می‌کنند تا وابستگی‌ها (Dependencies) شناسایی و به حداقل رسانده شوند. در اینجا سایزبندی نسبی کلان انجام می‌شود و هر قسمت از Backlog به تیم مناسب اختصاص پیدا می‌کند.
سطح هر تیم: هر Development Team اقلام خود را جداگانه Refine می‌کند و وابستگی‌های باقی‌مانده را با تیم‌های دیگر هماهنگ می‌کند.

نتیجه‌ی این رویکرد یک چیز است: یک Increment یکپارچه در پایان هر Nexus Sprint، که شفافیت کاملی برای Product Owner و Stakeholderها ایجاد می‌کند.

گزارش‌دهی: ابزار اصلی، همان Product Backlog است

نویسندگان با یک جمله‌ی کوتاه اما قوی این بخش را باز می‌کنند:

«یک Product Backlog که به خوبی نگهداری می‌شود، تمام اطلاعات لازم برای گزارش‌دهی را در خود دارد.»

و Agile Manifesto را یادآوری می‌کنند:

«معیار اصلی پیشرفت، نرم‌افزار کارکننده است.»

Release Burn-down و مخروط عدم‌قطعیت

نویسندگان یک نمودار واقعی از یک محصول بزرگ با سه Development Team نشان می‌دهند. در این نمودار چند نکته‌ی آموزنده وجود دارد:

تا Sprint پنجم، تیم‌ها هنوز در حال یادگیری (Emergence) بودند — یادگیری درباره‌ی Domain، تکنولوژی، و نحوه‌ی همکاری. Velocity واقعی و پایدار از Sprint چهارم به بعد شکل گرفت.
از Sprint چهارم به بعد، اندازه‌ی Product Backlog بزرگ‌تر شد. این نشانه‌ای از کشف Scope جدید یا به‌روزرسانی تخمین‌ها بر اساس درک بهتر بود.

در این نمودار چهار خط رسم می‌شود:

خط نازک مشکی: Trendline (بر اساس رگرسیون Least Squares روی تمام داده‌ها)
خط ضخیم خاکستری: میانگین Velocity آخرین Sprint، برون‌یابی‌شده به آینده
دو خط نقطه‌چین: میانگین سه پایین‌ترین و سه بالاترین Velocity اسپرینت‌ها

فضای بین دو خط نقطه‌چین همان Cone of Uncertainty است که ریشه در پیش‌بینی مسیر طوفان‌های گرمسیری دارد.

استعاره‌ی طوفان

نویسنده از weather.com نقل می‌کند:

«مخروط پیش‌بینی نشان می‌دهد که مسیر طوفان با احتمال ۶۰ تا ۷۰ درصد درون مخروط باقی می‌ماند. مخروط با گذر زمان پهن‌تر می‌شود زیرا عدم‌قطعیت افزایش می‌یابد.»

اگر کلمه‌ی «طوفان» را با «Product Backlog» و «عموم مردم» را با «Stakeholders» جایگزین کنید، این جمله دقیقاً برای توسعه‌ی محصول هم صادق است. طوفان‌ها ۳۰ تا ۴۰ درصد اوقات از مخروط خارج می‌شوند — در توسعه‌ی نرم‌افزار هم Unknown-Unknownها وجود دارند.

نتیجه‌گیری نویسندگان صریح است:

«از Cone of Uncertainty به عنوان ابزاری برای یادآوری عدم‌قطعیت استفاده کنید، نه برای نشان دادن قطعیت.»

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

فصل ۸ — بخش پنجم: موانع Release و آیینه‌ی Scrum

آیا Release همیشه خوب است؟

نویسندگان با یک پرسش چالشی این بخش را باز می‌کنند: «آیا Major Release همیشه بد است؟» پاسخ آن‌ها صادقانه است — خیر، لزوماً نه. وقتی هزینه‌ی یک Release از ارزشی که تولید می‌کند بیشتر باشد (ROI منفی)، ممکن است Major Release استراتژی درستی باشد.

اما قبل از رسیدن به این نتیجه، نویسندگان تأکید می‌کنند که باید عدد داشت، نه حس. باید هزینه‌ها را محاسبه و توجیه کرد. اگر راهی برای کاهش هزینه‌ی Release وجود دارد، آن مسیر در اولویت است، نه اجتناب از Release.

موانع واقعی Release: سؤالات استراتژیک

نویسندگان فهرستی از عوامل می‌دهند که Release را گران و دردناک می‌کنند. این فهرست برای هر توسعه‌دهنده‌ی ارشدی آشناست:

مشکل فناوری: تست‌های دستی، فقدان CI/CD، وابستگی به محیط‌های دستی
فرآیندهای داخلی سنگین: تأییدیه‌های مرحله‌ای که برای هر Release باید از سر گذرانده شوند
مسائل Compliance: قوانین و استانداردهایی که هر تغییر کوچک را نیازمند ممیزی کامل می‌کنند
جذب‌پذیری مشتری (Customer Absorption): مشتری آمادگی پذیرش تغییر مداوم را ندارد
هزینه‌های محیطی: نیاز به سخت‌افزار جدید، محیط‌های Pilot، Migration داده، آموزش کاربران، نصب پیچیده

نکته‌ی کلیدی نویسندگان: هر کدام از این موانع، یک مشکل واقعی هستند که باید حل شوند — نه دلیلی برای Release نکردن. اگر Release دردناک است، باید آن عضله را تقویت کنید تا دیگر دردناک نباشد، نه اینکه از استفاده از آن امتناع کنید.

داستان واقعی: یک سال کار برای فهمیدن اشتباه

دان یک تجربه‌ی دردناک شخصی از فصل ۴ را دوباره نقل می‌کند، زیرا می‌گوید این‌جا دقیقاً به آن مربوط می‌شود:

روی یک پروژه‌ی یک‌ساله کار می‌کرد — یک محصول چاپ آنلاین. پنج ماه بعد، تیم توانسته بود فایل آپلود کند و چند گزینه‌ی ساده‌ی چاپ تنظیم کند. اما مدیریت اجازه نداد زودتر وارد Production شوند چون «هنوز تمام نشده بود.»

هفت ماه بعد، بعد از Release، فهمیدند که اکثر مشتریان اصلاً از گزینه‌های پیچیده‌ی Finishing استفاده نمی‌کنند. چیزی که واقعاً می‌خواستند؟ یک فیلد ساده برای «دستورالعمل‌های خاص» و توانایی چاپ پوسترهای بزرگ.

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

درس این داستان: تأخیر در Release، فرصت یادگیری را از بین می‌برد. هزینه‌ی نادانستن، گاهی از هزینه‌ی Release بیشتر است.

Water-Scrum-Fall: Scrum قلابی

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

برنامه‌ریزی سنتی ← تحلیل ← طراحی
    ↓
Sprint Planningهای متوالی (فقط برای پیاده‌سازی)
    ↓
Test و Release سنتی

این همان Water-Scrum-Fall است — Waterfall با پوشش Scrum. نشانه‌های آن:

«Analysis Sprint»، «Design Sprint»، «Test Sprint» جداگانه دارند
یک فاز برنامه‌ریزی مفصل قبل از شروع Sprint‌ها وجود دارد
پس از آخرین Sprint، یک فاز تست و تثبیت مجزا برای Release دارند
هرگز در پایان هر Sprint چیز کارکننده‌ای برای Release وجود ندارد

چرا این مشکل‌ساز است؟ چون تمام ریسک‌های اصلی — یکپارچه‌سازی، کیفیت واقعی، بازخورد مشتری — تا لحظه‌ی آخر به تعویق می‌افتند. همان چیزی که Scrum قرار بود آن‌ها را از بین ببرد.

Scrum مشکل شما را حل نمی‌کند — آن را آشکار می‌کند

نویسندگان با یک جمله‌ی کوتاه اما بسیار قدرتمند این بخش را جمع‌بندی می‌کنند:

«Scrum does not solve your problems, it reveals them.» «Scrum مشکلات شما را حل نمی‌کند، آن‌ها را آشکار می‌سازد.»

اگر تیمی با Scrum مشکل Release دارد، معنایش این نیست که Scrum کار نمی‌کند — معنایش این است که آن مشکل قبلاً هم وجود داشت، فقط پشت فرآیندهای سنگین پنهان بود. Scrum آن را از سایه بیرون می‌کشد و می‌گوید: «این مانع را ببین. الان باید با آن کنار بیایی».

تحلیل انتقادی: این همان چیزی است که Robert C. Martin در Clean Code از آن به‌عنوان «شفافیت دردناک» یاد می‌کند. یک سیستم با معماری بد، تحت فشار Agile، سریع‌تر خرد می‌شود. این ضعف Agile نیست — این قدرت آن است که ضعف‌های پنهان را زودتر هویدا می‌کند تا بتوان آن‌ها را اصلاح کرد، نه اینکه سال‌ها بعد با یک بحران بزرگ مواجه شد.

فصل ۸ — بخش ششم: Kickoff، راه‌اندازی صحیح از همان ابتدا

استعاره‌ی ماراتن

رالف این بخش را با یک تجربه‌ی شخصی آغاز می‌کند:

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

ارتباط این استعاره با توسعه‌ی محصول مستقیم است: راه‌اندازی درست، همان‌قدر که برای یک ماراتنِ ۴۲ کیلومتری حیاتی است، برای یک ابتکار نرم‌افزاری هم حیاتی است.

نویسندگان یک آسیب‌شناسی رایج را مطرح می‌کنند:

«راه‌اندازی ابتکارات توسعه‌ی محصول، اغلب یک فکر ثانویه است. “الان شروع کن، بعداً می‌گوییم چه می‌خواهیم” یک ذهنیت رایج است. نتیجه؟ توسعه‌دهندگانی با مهارت اشتباه که دنبال یک Vision فرموله‌نشده می‌دوند. این وضعیت در تمام سطوح ناامیدکننده است و نه Buy-in ایجاد می‌کند و نه تعهد واقعی.»

چارچوب Kickoff: سه رکن اصلی

نویسندگان به کتاب Liftoff اثر Diana Larsen و Ainsley Nies ارجاع می‌دهند و یک چارچوب سه‌گانه معرفی می‌کنند:

Purpose (هدف)  →  Context (زمینه)  →  Alignment (همسویی)

هیچ‌کدام از این سه رکن را نمی‌توان حذف کرد. بدون هرکدام، کل ساختار فرو می‌ریزد.

رکن اول: Purpose — هدف را در زمین فرو کنید

Purpose یعنی صریحاً مشخص کنید که کجا می‌روید و چرا:

Vision

چه تصویری از موفقیت دارید؟ این همان مفهومی است که در فصل ۲ کتاب به تفصیل بررسی شده.

Mission

اغلب نمی‌توان Vision را در یک گام بزرگ محقق کرد. Mission یعنی: اولین یا بعدی گام به سمت Vision چیست؟

رالف یک مثال واقعی می‌آورد:

«روی یک محصول کشاورزی کار می‌کردم. Vision این بود که با استفاده‌ی هوشمندانه از آب — که در آن منطقه منبعی کمیاب بود — محصول کشاورزی را ۲۰٪ افزایش دهیم. Mission اول ما این بود: حداقل ۱۰۰ کشاورز باید ثبت‌نام کرده و در Pilot شرکت کنند تا مدل ریاضی ما را Validate کنیم.»

Mission Tests

چطور می‌فهمید که در مسیر درست هستید؟ این همان مفهومی است که در فصل ۳ با عنوان EBMgt (Evidence-Based Management) بررسی شد. در مثال رالف، Mission Test ساده بود: ۱۰۰ کشاورز باید سود محصول را مشاهده کنند.

رکن دوم: Context — زمینه را شفاف کنید

Context یعنی همه‌ی عواملی که محیط توسعه را شکل می‌دهند:

Boundaries — مرزها

وابستگی‌ها (Dependencies) به سایر Component‌ها یا تیم‌ها کجاست؟
محیط فیزیکی کار چگونه است؟

Project Community Interaction — اکوسیستم ذینفعان

Stakeholderها چه کسانی هستند؟
مشتریان، تیم فروش، تیم بازاریابی، و کاربران نهایی — هر کدام در کجای تصویر قرار دارند؟

Committed Resources — منابع متعهدشده

بودجه‌ی سفر چقدر است؟
Infrastructure موجود چیست؟
Hardware و Software موردنیاز کدام‌اند؟

Prospective Analysis — تحلیل آینده‌نگرانه

این بخش صادقانه‌ترین قسمت Context است:

فرضیاتمان چیست؟ آیا با آنچه در اختیار داریم، هدفمان واقع‌بینانه است؟
تهدیدات و ریسک‌های شناخته‌شده کدام‌اند؟
وقتی اوضاع بد شد، چه چیزی اول فدا می‌شود؟ (کیفیت؟ Scope؟ زمان؟)
فرصت‌ها و مزایای بالقوه کدام‌اند؟

رکن سوم: Alignment — همسویی بسازید

Alignment یعنی تیم بر روی چگونگی کار مشترک با هم توافق می‌کند:

Values and Principles — ارزش‌ها و اصول

ارزش‌های ما چیست؟
چطور با هم کار و تعامل می‌کنیم؟ (یادآوری: پنج ارزش Scrum عبارت‌اند از Commitment، Openness، Focus، Respect، و Courage)

Core Team — تیم هسته‌ای

تیم Cross-functional ما از چه کسانی تشکیل شده؟
توسعه‌دهندگان چه میزان از وقتشان را روی این محصول صرف می‌کنند؟ (همان On-Product Index که در فصل ۳ معرفی شد)

Working Agreements — توافقنامه‌ی کاری

نویسندگان یک فهرست عملی از پرسش‌هایی که تیم باید با هم پاسخ دهد ارائه می‌کنند:

سؤال	هدف
آیا ساعت‌های کاری مشترک (Core Hours) داریم؟	هماهنگی ساعت حضور
آیا Remote Work تشویق می‌شود؟	روشن کردن انتظارات
Daily Scrum ما چه زمانی است؟	ریتم روزانه
Definition of Done ما چیست؟	معیار کیفیت مشترک
در صورت بروز تعارض، چه می‌کنیم؟	پروتکل حل مشکل

اجرای Kickoff: همه در یک اتاق

نویسندگان در مورد اجرا یک نکته‌ی محوری دارند:

«این یک کار تیمی است؛ هیچ‌چیز را در انزوا انجام ندهید. همه را در یک اتاق جمع کنید و با Facilitation قوی، اجازه دهید خودشان به پاسخ برسند.»

در مورد مدت‌زمان:

حداقل یک روز برنامه‌ریزی کنید
اگر یک روز کافی نیست، برخی کارهای آمادگی را قبل از Kickoff انجام دهید و سپس Kickoff را به‌عنوان رویداد اصلی برگزار کنید
برای تیم‌های بزرگ‌تر، می‌توان دو روز خارج از محل (Offsite) رفت و فعالیت‌های Team-forming را هم در آن گنجاند

تحلیل انتقادی: این بخش مستقیماً با اصل Richard Hackman همخوانی دارد که نویسندگان در فصل ۱ به آن اشاره کردند: «۳۰٪ از موفقیت یک تیم به نحوه‌ی راه‌اندازی آن بستگی دارد.» Working Agreements به‌ظاهر ساده‌اند، اما در عمل همان چیزهایی هستند که بیشترین Friction و بیشترین هدررفت انرژی را در تیم‌های نرم‌افزاری ایجاد می‌کنند — مخصوصاً وقتی کسی از آن‌ها صحبت نمی‌کند.

Customer Satisfaction — رضایت مشتری

«هدف کسب‌وکار این است که مشتری بسازد و نگهش دارد.» — پیتر دراکر

این یک lagging indicator است؛ یعنی خروجی عملکرد گذشته را اندازه می‌گیرد، نه عوامل ورودی آن را.

یکی از رایج‌ترین ابزارهای صنعتی برای سنجش رضایت مشتری، Net Promoter Score (NPS) است. NPS با پرسیدن یک سؤال کلیدی محاسبه می‌شود:

«از ۰ تا ۱۰، چقدر احتمال دارد که این محصول را به دوست یا همکارتان توصیه کنید؟»

کاربران بر اساس پاسخ‌شان به سه گروه تقسیم می‌شوند:

Promoters (امتیاز ۹-۱۰): مشتریان وفادار و پرشور که دیگران را به خرید تشویق می‌کنند.
Passives (امتیاز ۷-۸): مشتریانی راضی اما بی‌تفاوت که در معرض جذب رقبا هستند.
Detractors (امتیاز ۰-۶): مشتریانی ناراضی که با تبلیغات دهان‌به‌دهان منفی، به برند آسیب می‌زنند.

فرمول محاسبه: NPS = درصد Promoters − درصد Detractors

این عدد می‌تواند از −۱۰۰ (همه Detractor) تا +۱۰۰ (همه Promoter) باشد.

توصیه عملی نویسندگان: مکانیزم دریافت Feedback را مستقیماً داخل خود محصول بسازید. مایکروسافت آفیس در سال ۲۰۱۶ این قابلیت را به‌صورت استاندارد اضافه کرد.

Time to Market — سرعت رساندن ارزش به بازار

«Time-to-Market توانایی سازمان را در تحویل واقعی ویژگی‌ها، توابع، سرویس‌ها و محصولات جدید ارزیابی می‌کند. بدون مدیریت فعال این معیار، توانایی تحویل پایدار ارزش در آینده ناشناخته می‌ماند.» — EBMgt Guide

این حوزه شامل چهار معیار کلیدی است:

۱. Release Frequency — تناوب انتشار

این معیار نشان می‌دهد چه مدت طول می‌کشد تا ارزش واقعی به دست مشتری برسد.

نکته مهم: بسیاری از شرکت‌های بزرگ Release‌هایشان را بر اساس تقویم مالی (مثلاً هر فصل) تنظیم می‌کنند، نه بر اساس نیاز بازار. یک شرکت واقعاً چابک باید توانایی و اراده برای Release به‌اندازه کافی مکرر را داشته باشد.

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

۲. Release Stabilization — دوره تثبیت قبل از انتشار

بعد از اینکه توسعه ویژگی‌ها متوقف می‌شود (Feature Freeze)، چقدر طول می‌کشد تا نرم‌افزار آماده انتشار شود؟ این بازه شامل: تست رگرسیون، استقرار، پذیرش کاربر، مستندسازی و رفع باگ است.

⚠️ نقطه انتقادی نویسندگان: مفهوم «دوره تثبیت» در واقع نشانه‌ای از یک مشکل ریشه‌ای است. در Scrum انتظار می‌رود Increment هر Sprint کاملاً Done و مستقر باشد. اگر مجبور به «تثبیت» هستید، یعنی چیزی در فرآیند توسعه شکسته است. هرچه این دوره به صفر نزدیک‌تر باشد، بهتر است. Release Frequency مستقیماً توسط Release Stabilization محدود می‌شود.

۳. Cycle Time — زمان چرخه

مدت زمانی که طول می‌کشد تا یک مجموعه کلیدی از نیازهای مشتری به‌صورت کامل توسعه یابد و Release شود (از شروع کار تا انتشار، شامل دوره Stabilization).

این معیار با Release Stabilization رابطه مستقیم دارد: هرچه Stabilization طولانی‌تر باشد، Cycle Time بدتر می‌شود.

۴. On-Product Index — شاخص تمرکز روی محصول

این معیار نشان می‌دهد چه درصدی از ظرفیت تیم توسعه واقعاً صرف کار روی محصول می‌شود، نه صرف موانع سازمانی، جلسات بی‌هدف، یا وظایف موازی.

مشکل رایج در سازمان‌ها این است که تیم‌ها روی چندین پروژه هم‌زمان کار می‌کنند (Full-Time Equivalent یا FTE). این وضعیت یک Positive Reinforcement Loop منفی ایجاد می‌کند:

تعداد پروژه‌های فعال بالا → رقابت بر سر زمان افراد بیشتر → توانایی اتمام پروژه‌ها کمتر → پروژه‌های کمتری تمام می‌شوند → نیاز به شروع پروژه‌های اضطراری («Task Force», «Tiger Team») → این تیم‌ها از پروژه‌های موجود سرک می‌کشند → حلقه باز هم بدتر می‌شود.

راه‌حل: به‌جای فکر کردن درباره «پروژه‌های طولانی»، درباره «ارسال ارزش از طریق محصولات» فکر کنید. اگر تعداد محصولات در Portfolio از تعداد Development Team‌ها بیشتر باشد، از ظرفیت (WIP Limit) تجاوز کرده‌اید و همه چیز کند می‌شود.

حوزه سوم: Ability to Innovate — توانایی نوآوری

«Ability to Innovate توانایی سازمان را برای تحویل ویژگی‌های جدیدی که به کاربران واقعی ارائه می‌شود، ارزیابی می‌کند.» — EBMgt Guide

این حوزه شامل چهار معیار است:

۱. Installed Version Index — شاخص نسخه نصب‌شده

چند درصد از کاربران از آخرین نسخه محصول استفاده می‌کنند؟

این عدد مستقیماً نشان می‌دهد چه درصدی از کاربران در حال دریافت ارزش آخرین Release هستند. اگر ۷۰٪ از کاربران روی آخرین نسخه باشند، تنها همان ۷۰٪ از ویژگی‌های جدید بهره‌مند می‌شوند.

عامل اصلی پایین بودن این شاخص، هزینه جذب (Absorption Cost) است؛ یعنی هزینه‌هایی که کاربر باید برای Upgrade متحمل شود:

زمان نصب
نیاز به سخت‌افزار جدید
آموزش کاربران
مهاجرت داده
اجرای پایلوت

رصد این شاخص می‌تواند توجیه خوبی برای سرمایه‌گذاری در کاهش هزینه‌های جذب باشد. همچنین، هرچه کاربران کمتر روی نسخه‌های قدیمی باشند، زمان پشتیبانی کمتری می‌برد و ظرفیت بیشتری برای نوآوری آزاد می‌شود.

۲. Usage Index — شاخص استفاده

آیا ویژگی‌هایی که ساختید واقعاً استفاده می‌شوند؟

این معیار نشان می‌دهد کاربران چگونه از محصول استفاده می‌کنند: کدام ویژگی‌ها پرکاربردترند؟ کدام‌ها به‌ندرت لمس می‌شوند؟ آیا رفتار کاربران با فرضیات اولیه تیم تطابق دارد؟

داده‌های گزارش Standish Chaos در سال‌های ۲۰۰۲ و ۲۰۱۴ نتیجه‌ای هشداردهنده دارند: تنها ۲۰٪ از قابلیت‌های یک محصول «اغلب» یا «همیشه» استفاده می‌شوند، در حالی که ۵۰٪ از ویژگی‌ها به‌ندرت یا هرگز استفاده نمی‌شوند.

این یعنی نیمی از بودجه توسعه ممکن است صرف ویژگی‌هایی شده باشد که هیچ‌کس از آن‌ها استفاده نمی‌کند.

۳. Innovation Rate — نرخ نوآوری

چه درصدی از بودجه توسعه صرف ویژگی‌های جدید می‌شود، نه نگهداری و رفع باگ؟

این معیار در واقع معکوس Technical Debt است. هرچه کد‌بیس ناسالم‌تر باشد، زمان و هزینه بیشتری صرف نگهداری می‌شود و ظرفیت کمتری برای نوآوری باقی می‌ماند. نویسندگان این وضعیت را به «ورشکستگی فنی» تشبیه می‌کنند: «بیایید Chapter 11 اعلام کنیم و از نو شروع کنیم.»

داده‌های Forrester Research در سال ۲۰۱۰ نشان می‌دهد که در آن دوره، تنها ۲۹٪ از بودجه‌های IT صرف ساختن ویژگی‌های جدید می‌شد؛ ۵۳٪ صرف نگهداری و ۱۸٪ صرف توسعه ظرفیت (Infrastructure) می‌شد.

سه روش عملی برای اندازه‌گیری Innovation Rate:

شمارش نسبت Product Backlog Itemهای جدید در مقابل آیتم‌های مربوط به Technical Debt، باگ، و ارتقا
اندازه‌گیری نسبت افراد تیم نگهداری در برابر تیم توسعه محصول جدید
در صورت غیرقابل‌پیش‌بینی بودن کار نگهداری، اندازه‌گیری زمان صرف‌شده روی آیتم‌های Unplanned در هر Sprint

۴. Defects — باگ‌ها

این رایج‌ترین معیار در توسعه نرم‌افزار است. نکته مهم: عدد خام باگ‌ها به‌تنهایی معنادار نیست؛ مهم‌تر از آن روند تغییر این عدد در طول زمان است. افزایش پیوسته تعداد باگ‌ها نشانه‌ای از کاهش کیفیت سیستم و در نتیجه کاهش ظرفیت نوآوری است.

کجا رفت پولتان؟ — ترکیب چهار معیار

نویسندگان ترکیبی تأمل‌برانگیز از چهار معیار ارائه می‌دهند که نشان می‌دهد از هر ۱ دلار سرمایه‌گذاری، در میانگین صنعت، فقط ۶ سنت ROI واقعی به مشتری می‌رسد:

معیار	مقدار	محاسبه
Innovation Rate	29%	از $1.00 → $0.29 می‌ماند
On-Product Index	80%	از $0.29 → $0.23 می‌ماند
Usage Index	35%	از $0.23 → $0.08 می‌ماند
Installed Version Index	70%	از $0.08 → $0.06 می‌ماند

این یعنی ۹۴٪ از بودجه در مسیر به هدر می‌رود. این نمودار به‌تنهایی می‌تواند توجیه‌کننده سرمایه‌گذاری جدی در کیفیت، اتوماسیون، ساختار تیمی، و راهنمایی کاربر باشد.

Negative Value — ارزش منفی

یک فرض رایج اشتباه این است که هر Release ارزش مثبت ایجاد می‌کند. اما ارزش می‌تواند منفی هم باشد. طبق مطالعات متعدد، مردم ۳ تا ۷ برابر بیشتر تجربیات منفی را با دیگران به اشتراک می‌گذارند.

ارزش منفی دو نوع است:

مرئی (Visible): باگ‌های جدید که ویژگی‌های مهم را از کار می‌اندازند، Downtime، کاهش عملکرد، تخریب تجربه کاربری.

نامرئی (Invisible): این نوع خطرناک‌تر است چون مشتری آن را مستقیم نمی‌بیند؛ مثل ویژگی‌هایی که هیچ‌کس از آن‌ها استفاده نمی‌کند اما همچنان نگهداری می‌شوند. یا کدی که به‌خاطر عجله نوشته شده و به بدهی فنی تبدیل شده است.

«Technical Debt به معنای ‘Done نبودن’ نیست.»

گاهی تصمیم کسب‌وکار برای انباشت Technical Debt درست است — مثلاً برای سبقت‌گرفتن از رقیب در زمان‌بندی. اما باید آگاهانه انتخاب شود و بازپرداخت آن برنامه‌ریزی شود. تأخیر در پرداخت این بدهی، درست مانند بدهی مالی، بهره دارد.

Value Neutrality و Perversion of Metrics

تمام معیارهای معرفی‌شده باید خنثی از قضاوت باشند. هدف آن‌ها تولید اطلاعات برای تصمیم‌گیری بهتر است، نه اعمال فشار یا کنترل رفتار. این اصل را Value Neutrality می‌نامند.

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

Budgeting — بودجه‌بندی

در سازمان‌های Phase-Driven (مرحله‌محور)، فرآیند بودجه‌بندی چهار مرحله دارد: آماده‌سازی، تأیید، اجرا و کنترل، و ارزیابی.

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

رویکرد Agile: به‌جای قراردادن قید و بند قبل از یادگیری، باید از Emergence (ظهور تدریجی دانش) استفاده کرد. با ساختن یک بخش کوچک از محصول — بخشی که ریسک‌های فنی یا ویژگی‌های کلیدی را آزمایش کند — داده‌های واقعی به دست می‌آید که می‌تواند تصمیم Go/No-Go را هدایت کند.

هزینه این یادگیری ساده محاسبه می‌شود: تعداد اعضای Development Team × مدت دوره یادگیری. اغلب چند Sprint کافی است — و این هزینه حتی ممکن است از زمان لازم برای تهیه یک برنامه و بودجه جامع کمتر باشد.

بودجه‌بندی Agile — مدل FEED-ME

نویسندگان شش گام عملی برای بودجه‌بندی چابک ارائه می‌دهند که آن را با مخفف FEED-ME می‌شناسند:

Fund products, not projects — به‌جای تأمین مالی پروژه، محصول را تأمین مالی کنید. یک Sprint دو هفته‌ای که ۵۰,۰۰۰ دلار هزینه دارد، معادل نرخ سالانه ۱.۳ میلیون دلار است. این منظر، بحث را از «پروژه تموم شد» به «محصول چه ارزشی دارد» تغییر می‌دهد.
Empower the Product Owner — به Product Owner اختیار واقعی بدهید. به‌جای اینکه Scope، Schedule و Budget از بیرون تعیین شوند، PO باید مسئولیت مالی داشته باشد.
Establish transparency — به‌جای پیروی از یک برنامه خطی، حلقه‌های بازخورد تجربی ایجاد کنید و پیوسته بپرسید: «آیا هنوز در مسیر درست هستیم؟»
Demonstrate value sooner — هر چه بیشتر Release کنید، Stakeholder‌ها سریع‌تر بازگشت سرمایه می‌بینند و تمایل بیشتری به ادامه یا افزایش بودجه خواهند داشت.
Manage stakeholder expectations — مدام به Stakeholder‌ها گزارش دهید که پول کجا می‌رود و چه ارزشی در ازای آن دریافت می‌شود. پیچیدگی ذاتی ساختن محصول را به آن‌ها یادآوری کنید.
Employ empirical budgeting — بودجه را نه بر اساس برنامه اولیه، بلکه بر اساس شواهد جمع‌آوری‌شده در طول توسعه تنظیم کنید. بودجه ممکن است نیاز به افزایش، کاهش، تغییر مسیر یا حتی قطع داشته باشد.

سه سناریوی بودجه‌بندی ثابت

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

حالت اول — شما در فرآیند بودجه نقش دارید: یک Product Backlog بسازید، Velocity احتمالی را با Development Team تعیین کنید، تعداد Sprint‌ها را حساب کنید و هزینه هر Sprint را در آن ضرب کنید.

حالت دوم — بودجه به شما تحمیل شده: همان مراحل اول را انجام دهید، اما به‌جای تعیین هزینه، ببینید با بودجه داده‌شده چه بخشی از Product Backlog قابل پوشش است.

حالت سوم — Fixed Budget برای Fixed Scope (بدترین حالت):

بدانید که تمام ریسک روی دوش شماست، پس هزینه را بالاتر اعلام کنید.
برای هر Development Team یک یا دو عضو اضافه در نظر بگیرید تا ریسک تغییرات پوشش داده شود.
تغییرات Scope را فقط بپذیرید اگر ظرفیت داشته باشید یا اگر با آیتم هم‌اندازه‌ای تعویض شوند؛ در غیر این صورت کیفیت محصول قربانی می‌شود.
بودجه را حتماً شامل یک دوره نگهداری پس از Release کنید.

نکته انتقادی نویسندگان: بهترین کاری که می‌توانید در مقابل تمام این ریسک‌ها انجام دهید این است که در پایان هر Sprint یک محصول Done و واقعاً کارا تحویل دهید. وقتی این کار را انجام می‌دهید، سؤال اصلی دیگر «آیا به موقع تحویل می‌دهیم؟» نیست، بلکه «آیا از هر Sprint بهترین ROI را می‌گیریم؟» است.

Governance and Compliance — حاکمیت و انطباق

دو ارزش اول Agile Manifesto در سال ۲۰۰۱ عبارتند از:

«افراد و تعاملات بر فرآیندها و ابزارها» «نرم‌افزار کارا بر مستندات جامع»

هر دو به نوعی اشاره به اتلاف بالقوه در فعالیت‌های حاکمیتی دارند. اما آیا این یعنی همه Governance اتلاف است؟

دو دسته مستندات

نویسندگان مستندات را به دو دسته تقسیم می‌کنند:

مستندات داخلی (چپ)	مستندات خارجی (راست)
Requirements	User Guides
Business Rules	Training Materials
Test Cases	Legal Compliance (Sarbanes-Oxley)
UI Mock-ups	Security Compliance
Designs	Legal Traceability Matrix (FDA, FAA)
Coding Style Guides	Support & Maintenance Guides

مستندات سمت چپ توسط Development Team مصرف می‌شوند؛ مستندات سمت راست توسط Stakeholder‌های بیرون از تیم. نتیجه عملی این تقسیم:

مستندات داخلی: باید در Sprint Backlog یا Definition of Done قرار گیرند.
مستندات خارجی: باید در Product Backlog یا در Definition of Done باشند.

دو دلیل اصلی برای Governance داخلی

دلیل اول — بی‌اعتمادی: به تیم اعتماد ندارند، پس از آن‌ها می‌خواهند کارشان را مستند کنند. در Scrum این بی‌اعتمادی با تولید Increment واقعی و کارا در پایان هر Sprint برطرف می‌شود.

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

مشکل Governance سنتی

در رویکرد Waterfall، نقاط کنترل Governance با Milestone‌های بین فازها همراستا هستند. نتیجه: تا وقتی چیزی ساخته نشده، تنها «کاغذبازی» وجود دارد. و زمانی که اشتباهی رخ می‌دهد، معمولاً Governance بیشتر می‌شود که به نوبه خود Release را کندتر می‌کند.

یک مثال واقعی از کتاب: یک سازمان خرده‌فروشی با چرخه‌های Release 6 تا 12 ماهه، یک قانون داخلی داشت که برای هر Release نیاز به ۱۷ امضا بود — یک بار در Sprint Planning و یک بار قبل از Release. وقتی تیم سعی کرد هر Sprint دو هفته‌ای Release کند، این قانون به گلوگاه فوری تبدیل شد.

Agile A4 Sprint Report — جایگزین عملی

به‌جای مستندات حجیم، نویسندگان Agile A4 Sprint Report را پیشنهاد می‌دهند که از Toyota A3 Reports الهام گرفته است. این گزارش در یک صفحه A4 خلاصه می‌شود و شامل:

بالا چپ: خلاصه Sprint گذشته، یادگیری‌ها و مشکلات
پایین چپ: Happiness Index تیم
پایین چپ (ادامه): ریسک‌هایی که Scrum به‌تنهایی نمی‌تواند آن‌ها را مدیریت کند، با احتمال و تأثیر هر ریسک
بالا راست: Burn-Down نسبت به Product Backlog
پایین راست: تعداد Bug‌های باز
مرکز: آیا محصول «Done» است و می‌توان آن را Release کرد؟

این گزارش هر Sprint به‌روز می‌شود و در معرض دید قرار می‌گیرد تا روندها از Sprint به Sprint قابل مقایسه باشند.

کتاب, مهندسی, برنامه_نویسی

توضیحات

نظر

نظر

مشخصات

بخش‌هایی از کتاب

فصل ۱: مدیریت چابک محصول (Agile Product Management)

بخش اول: ذهنیت محصول در مقابل ذهنیت پروژه (Product Mindset vs. Project Mindset)

تحلیل انتقادی: چرا موفقیت پروژه‌ها به معنای موفقیت کسب‌وکار نیست؟

بخش دوم: ذهنیت محصول‌محور (Product Mindset) — رویکرد جایگزین

Product Mindset چیست؟

تفاوت بنیادین در جهت‌گیری

مزایای Product Mindset

آسیب‌های Project Mindset

نکته کلیدی نویسنده

بخش سوم: خلأ مدیریت محصول (Product Management Vacuum) و سه V

لایه‌های برنامه‌ریزی در یک سازمان

خلأ وقتی پر نشود چه اتفاقی می‌افتد؟

راه‌حل: سه V

V اول: Vision (چشم‌انداز)

V دوم: Value (ارزش)

V سوم: Validation (اعتبارسنجی)

بخش چهارم: Product Owner و انواع آن

چرا نقش مهم‌تر از عنوان است؟

۱. Scribe (منشی)

۲. Proxy (واسط)

۳. Business Representative (نماینده کسب‌وکار)

۴. Business Sponsor (حامی مالی)

۵. Entrepreneur (کارآفرین) — ایده‌آل‌ترین نوع

خط فاصل بین دو دسته

هشدار مهم نویسنده

بخش پنجم: تعریف محصول، قانون Conway و قانون بابانوئل

محصول چیست؟

دام رایج: Component را با Product اشتباه گرفتن

مثال خودرو: از کجا شروع کنیم؟

محصول Viable چیست؟

قانون بابانوئل (Santa Claus Rule)

وقتی محصول واقعاً بزرگ شد: Value Domains

فصل ۲: Vision (چشم‌انداز) — بخش اول

Vision چیست؟ تعریف دقیق

Business Modeling: نقطه شروع Vision

Product Vision: از Canvas به جمله‌ای که الهام می‌دهد

تکنیک Product Box

تکنیک Elevator Pitch

فصل ۲: Vision — بخش دوم (Pervasive کردن Vision و استراتژی فنی)

Vision باید Pervasive باشد

چگونه Vision را در Scrum زنده نگه دارید؟

استراتژی فنی: بخشی که Product Ownerها نادیده می‌گیرند

Product Owner و دانش فنی

هشدار مهم: زمان‌بندی استراتژی

فصل ۳: Value (ارزش) — بخش اول

ارزش کجا خلق می‌شود؟

معیارهای اشتباه و معیارهای درست

Evidence-Based Management (EBMgt)

KVA اول: Current Value (ارزش جاری)

KVA دوم: Time to Market (زمان ورود به بازار)

KVA سوم: Ability to Innovate (توانایی نوآوری)

هشدار: Perversion of Metrics

فصل ۳: Value — بخش دوم (Negative Value، Technical Debt و مدل Kano)

Negative Value: ارزش منفی

Technical Debt: بدهی فنی

مدل Kano و تعریف MVP

الگوهای MVP

Pivot یا Persevere؟

فصل ۵: Empiricism (تجربه‌گرایی) — بخش اول

مشکل پیچیدگی

راه‌حل ساده: ترموستات

تفاوت Complicated و Complex

سه ستون Empiricism در Scrum

چرا Scrum کار می‌کند؟

فصل ۵: Empiricism — بخش دوم (پیچیدگی در توسعه محصول)

از اتاق کنفرانس به توسعه محصول

پیچیده‌تر از اتاق کنفرانس

Scrum به عنوان ترموستات محصول

ریسک‌پذیری در محیط پیچیده

Quiz فصل ۵ — مرور پاسخ‌ها

فصل ۶: Scrum

بخش اول — چرا یک Framework؟ (و نه یک Process)

Scrum یک Framework است، نه یک Process

متافور اجاره در برابر خرید خانه

تله‌ی کپی از تیم Pilot