داستان

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

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

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

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

• «وای، به همه این داستان‌هایی که قرار است در آن‌ها ثبت‌نام کنیم نگاه کنید» (محدوده)
• «به تمام داستان‌هایی که در این تکرار انجام دادیم نگاه کنید» (پیشرفت)

در حالی که هر کسی می‌تواند داستان بنویسد ، تأیید آنها در تبم بک لاگ و پذیرش آنها در خط پایه سیستم بر عهده مالک محصول است. البته، چسب‌ها به خوبی در سراسر Enterprise مقیاس نمی‌شوند، بنابراین داستان‌ها اغلب به سرعت به ابزار Agile Lifecycle Management (ALM) منتقل می‌شوند. همانطور که در زیر توضیح داده شده است، دو نوع داستان وجود دارد، داستان های کاربر و داستان های فعال کننده.

منابع داستان

همانطور که شکل ۱ نشان می دهد، داستان ها معمولاً با تقسیم کردن ویژگی های کسب و کار و توانمندساز هدایت می شوند.

شکل ۱. مثالی از یک ویژگی تجاری که به داستان تقسیم شده است

داستان های کاربر

داستان های کاربر ابزار اصلی برای بیان عملکرد مورد نیاز است. آنها اساساً جایگزین مشخصات الزامات سنتی می شوند. با این حال، در برخی موارد، آنها به عنوان وسیله ای برای توضیح و توسعه رفتار سیستم عمل می کنند که بعداً در مشخصاتی که از انطباق، تأمین کنندگان، قابلیت ردیابی یا سایر نیازها پشتیبانی می کند، ثبت می شود. از آنجا که آنها بر روی کاربر به عنوان موضوع مورد علاقه تمرکز می کنند و نه سیستم، داستان های کاربر ارزش و مشتری محور هستند.
برای حمایت از این، شکل پیشنهادی عبارت «فرم صدای کاربر» به شرح زیر است: به عنوان یک (نقش کاربر)، می خواهم (فعالیت) را انجام دهم تا (ارزش کسب و کاری) با استفاده از این قالب، تیم ها راهنمایی شوند تا بفهمند چه کسی از سیستم استفاده می کند، با آن چه می کند و چرا آن را انجام می دهد. استفاده از قالب “صدای کاربر” به طور معمول باعث افزایش شایستگی دامنه تیم می شود. آنها نیازهای تجاری واقعی کاربران خود را بهتر درک می کنند. شکل ۲ یک مثال را نشان می دهد.

شکل ۲. مثال داستان کاربر در فرم صدای کاربر

همانطور که در Design Thinking توضیح داده شد، پرسوناها ویژگی های خاص کاربران نماینده را توصیف می کنند که به تیم ها کمک می کند تا کاربر نهایی خود را بهتر درک کنند. نمونه شخصیت‌های سوارکار در شکل ۲ می‌تواند یک «جین» ماجراجوی پرهیجان و «باب» یک سوارکار ترسو باشد. سپس شرح داستان‌ها می‌توانند به این شخصیت‌ها اشاره کنند (همانطور که جین می‌خواهم…).
در حالی که صدای داستان کاربر معمولی است، هر سیستمی با کاربر نهایی تعامل ندارد. گاهی اوقات «کاربر» یک دستگاه (مثلاً چاپگر) یا یک سیستم (مثلاً سرور تراکنش) است.
در این موارد، داستان می تواند شکل نشان داده شده در شکل ۳ را به خود بگیرد.

شکل ۳. مثالی از یک داستان کاربر با یک “سیستم” به عنوان کاربر

داستان های توانمندساز

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

شکل ۴. مثال داستان فعال کننده

انواع دیگری از داستان های توانمنساز وجود دارد، از جمله:

• Refactoring و Spikes (همانطور که به طور سنتی در XP تعریف شده است)
• ایجاد یا بهبود زیرساخت توسعه/استقرار
• انجام کارهایی که نیاز به تعامل انسانی دارند (مثلاً فهرست کردن ۱ میلیون صفحه وب)
• ایجاد تنظیمات محصول یا اجزای مورد نیاز برای اهداف مختلف
• تأیید کیفیت سیستم (به عنوان مثال، تست عملکرد و آسیب پذیری)

داستان‌های فعال‌کننده درست مانند داستان‌های کاربر، معمولاً با نشان دادن دانش به‌دست‌آمده، مصنوعات تولید شده، یا رابط کاربری، خرد، یا ماکت نشان داده می‌شوند.

نوشتن داستان های خوب

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

۳Cs: کارت، مکالمه، تایید

ران جفریس، یکی از مخترعان XP، با توصیف ۳Cهای یک داستان اعتبار دارد:

کارت – بیانیه قصد کاربر را با استفاده از کارت فهرست، یادداشت چسبنده یا ابزار ضبط می کند. کارت های شاخص یک رابطه فیزیکی بین تیم و داستان ارائه می دهند. اندازه کارت از نظر فیزیکی طول داستان و پیشنهادات زودهنگام را برای ویژگی رفتار سیستم محدود می کند. کارت‌ها همچنین به تیم کمک می‌کنند تا محدوده آینده را «احساس» کند، زیرا بین داشتن ده کارت و نگاه کردن به ده خط تفاوت وجود دارد.

گفتگو – نشان دهنده یک “وعده برای گفتگو” در مورد داستان بین تیم، مشتری (یا نماینده مشتری)، PO (که ممکن است نماینده مشتری باشد) و سایر سهامداران است. بحث برای تعیین رفتار دقیق‌تر مورد نیاز برای اجرای هدف ضروری است. مکالمه ممکن است ویژگی های بیشتری را در قالب معیارهای پذیرش (تایید زیر) یا پیوست های داستان کاربر ایجاد کند. مکالمه تمام مراحل چرخه زندگی داستان را در بر می گیرد:

• پالایش بک لاگ
• برنامه ریزی
• پیاده سازی
• نسخه ی نمایشی

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

تائیدیه – معیارهای پذیرش اطلاعات مورد نیاز برای اطمینان از اجرای صحیح داستان و پوشش عملکرد و NFR های مربوطه را فراهم می کند. شکل ۵ یک مثال را نشان می دهد. برخی از تیم‌ها معمولاً از بخش تأیید کارت داستان برای نوشتن نسخه نمایشی استفاده می‌کنند.

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

شکل ۵. معیارهای پذیرش داستان با BDD

سرمایه گذاری در داستان های خوب

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

• I- مستقل (از جمله داستان های دیگر)
• N – قابل مذاکره (یک بیانیه منعطف از قصد، نه یک قرارداد)
• V – ارزشمند (ارائه یک برش عمودی با ارزش به مشتری)
• E – قابل تخمین (کوچک و قابل مذاکره)
• S – کوچک (در یک تکرار قرار می گیرد)
• T – قابل آزمایش (به اندازه کافی فهمیده شده است که چگونه آن را آزمایش کنید)

تقسیم خوب

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

• مراحل گردش کار
• تغییرات قوانین کسب و کار
• تلاش عمده ساده/پیچیده
• تغییرات در داده ها
• روش های ورود داده ها
• کیفیت سیستم معوق
• عملیات (مثلا، ایجاد، خواندن، به‌روزرسانی، حذف [CRUD])
• سناریوهای مورد استفاده
• سنبله شکست

شکل ۶ نمونه ای از تقسیم بر اساس سناریوهای مورد استفاده را نشان می دهد.

شکل ۶. نمونه ای از تقسیم یک داستان بزرگ به داستان های کوچکتر

تخمین داستان ها

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

حجم – چقدر است؟
پیچیدگی – چقدر سخت است؟
دانش – چه چیزی شناخته شده است؟
عدم قطعیت – چه چیزی ناشناخته است؟

نقاط داستان نسبی هستند، بدون ارتباط با واحد اندازه گیری خاصی. اندازه (تلاش) هر داستان نسبت به کوچکترین داستان، که اندازه “یک” به آن اختصاص داده شده است، تخمین زده می شود. یک دنباله فیبوناچی اصلاح شده (۱، ۲، ۳، ۵، ۸، ۱۳، ۲۰، ۴۰، ۱۰۰) اعمال می شود که عدم قطعیت ذاتی را در تخمین، به خصوص اعداد بزرگ (مثلاً ۲۰، ۴۰، ۱۰۰) منعکس می کند.

تخمین پوکر

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

• شرکت کنندگان شامل همه اعضای تیم هستند
• به هر برآوردگر یک دسته کارت داده می شود که حاوی دنباله فیبوناچی اصلاح شده است
• PO شرکت می کند اما تخمین نمی زند
• Scrum Master/Team Coach شرکت می کند اما تخمین نمی زند مگر اینکه کار توسعه واقعی را انجام دهند
• برای هر اقلام بک لاگ که باید تخمین زده شود، PO شرح داستان را می خواند
• سوالات مطرح و پاسخ داده می شود
• هر برآوردگر به طور خصوصی یک کارت تخمین را انتخاب می کند که نشان دهنده برآورد آنها است
• همه کارت‌ها به طور همزمان برگردانده می‌شوند تا از سوگیری جلوگیری شود و همه تخمین‌ها قابل مشاهده باشند
• برآوردگران حد بالا و پایین تخمین های خود را توضیح می دهند
• پس از بحث، هر برآوردگر با انتخاب یک کارت، مجدداً برآورد می کند
• برآوردها احتمالاً همگرا خواهند شد. در غیر این صورت، روند تکرار می شود

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

سرعت

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

ظرفیت

ظرفیت قسمتی از سرعت تیم است که برای هر دوره خاصی در دسترس است. تعطیلی‌ها، آموزش‌ها و رویدادهای دیگر ممکن است باعث شود که اعضای تیم برای قسمتی از اهداف یک دوره قادر به کمک به تحقق اهداف این دوره نباشند. این امر سرعت بالقوه بیشینه تیم برای آن دوره را کاهش می‌دهد. به عنوان مثال، یک تیم که میانگین ۴۰ امتیاز را در هر دوره تحویل می‌دهد، اگر یکی از اعضای تیم برای یک هفته در تعطیلی باشد، سرعت بیشینه خود را به ۳۶ اصلاح خواهد کرد. با اطلاع از این موضوع به صورت پیشین، تیم فقط به حداکثر ۳۶ امتیاز داستانی در طول برنامه‌ریزی دوره تعهد می‌دهد. همچنین این موضوع در طول برنامه‌ریزی PI به پیش‌بینی ظرفیت واقعی موجود برای هر دوره در PI کمک می‌کند، تا تیم در زمان تعیین اهداف PI خود از تعهد زیاد خودداری کند.

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

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

• به هر برنامه‌نویس آزمایش‌کننده در تیم هشت امتیاز برای تکرار دو هفته‌ای بدهید (یک امتیاز برای هر روز کاری ایده‌آل، کم کردن دو روز برای سربار کلی).
• برای روز تعطیلات و تعطیلات هر عضو تیم یک امتیاز کم کنید.
• یک داستان کوچک پیدا کنید که کدگذاری آن نیم روز و تست و اعتبارسنجی آن نیم روز طول می کشد. اسمش را بگذار “یک”.
• هر داستان دیگری را نسبت به آن «یک» تخمین بزنید.

مثال:

با فرض یک تیم شش نفره متشکل از سه توسعه‌دهنده، دو آزمایش‌کننده و یک PO، بدون تعطیلات یا تعطیلات، سرعت اولیه تخمینی = ۵ × ۸ امتیاز = ۴۰ امتیاز/تکرار.(توجه: اگر یکی از توسعه‌دهندگان و آزمایش‌کننده‌ها نیز Scrum Master/Team Coach باشد، ممکن است کمی پایین‌تر تنظیم شود.) به این ترتیب، نقاط داستان تا حدودی در بین تیم ها قابل مقایسه است. مدیریت می‌تواند هزینه یک نقطه داستان را بهتر درک کند و هزینه یک ویژگی یا حماسه آینده را با دقت بیشتری تعیین کند. در حالی که تیم ها تمایل دارند سرعت خود را در طول زمان افزایش دهند – و این چیز خوبی است – در واقعیت، این تعداد تمایل دارد ثابت بماند. سرعت یک تیم به مراتب بیشتر تحت تأثیر تغییر اندازه تیم و زمینه فنی قرار می گیرد تا تغییرات بهره وری.

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

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

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