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

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

#BDD
#behavior_driven_development


@code_crafters

ترانه ی زیبای فرانسوی به نام برف می بارد
اثر شکوهمند

سالواتور آدامو

#free

@code_crafters

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

roadmap.sh/backend


#free

@code_crafters

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


https://survey.alchemer.com/s3/8009809/python-developers-survey-2024

در پروژه‌های نرم‌افزاری، مدیریت و نگهداری کد منبع یکی از بخش‌های مهم توسعه هستش، ما از ابزارهای متعددی برای این منظور استفاده می‌کنیم، مثه GitLab، Bitbucket و GitHub. این پلتفرم‌ها با فراهم کردن قابلیت همکاری و اشتراک‌گذاری کد، به توسعه‌دهندگان این امکان رو‌ میدن تا به راحتی تغییرات در کد رو مدیریت و دنبال کنه. اما هسته اصلی تمام این ابزارها، Git هستش که در اکثر سازمان‌ها به عنوان استاندارد مدیریت نسخه مورد استفاده قرار می‌گیره (هرچند هنوز روش‌هایی مثل زیپ کردن کد منبع هم در برخی تیم‌ها دیده می‌شود😅)

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

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

1. feat: افزودن یک ویژگی جدید به کد
2. fix: رفع یک مشکل یا باگ
3. docs: تغییرات مرتبط با مستندات
4. style: تغییرات فرمت‌بندی که تأثیری بر عملکرد یا معنای کد ندارند (مانند فاصله‌گذاری یا استفاده از نقطه‌ویرگول)
5. refactor: تغییرات در ساختار کد بدون تغییر در عملکرد یا رفع باگ
6. perf: تغییراتی که به بهبود عملکرد منجر می‌شوند
7. test: اضافه یا تغییر تست‌های نرم‌افزار
8. chore: تغییرات مرتبط با ابزارها، کتابخانه‌ها یا فرایندهای پشتیبان (مثل تنظیمات build)
9. ci: تغییرات مربوط به سیستم‌های یکپارچه‌سازی مداوم و استقرار

بیایید چندتا مثال بزنیم
۱. افزودن ویژگی‌های جدید
- افزودن یک قابلیت جدید به سیستم ثبت‌نام:

feat(auth): add user registration with email verification

- اضافه کردن پنل ادمین جدید:

feat(admin): add dashboard for managing users and orders

۲. رفع باگ‌ها
- رفع مشکل ورود کاربران:

  fix(auth): fix login issue with incorrect password handling

- رفع خطای محاسبه مالیات در فاکتورها:

fix(invoice): correct tax calculation in final price

۳. مستندسازی
- اضافه کردن راهنمای نصب برای پروژه:

  docs: add installation guide for new developers

- به‌روزرسانی README:

docs: update README with new API endpoints

۴. تغییرات فرمت و سبک کد
- بهبود خوانایی کد:

style: format code according to eslint rules

- استفاده از کاما در جای درست:

style: add missing commas in product component

۵. بازسازی و بازنویسی کد
- بازنویسی یک تابع بزرگ برای ساده‌تر شدن:

refactor(cart): split calculateTotal function into smaller functions

- بهینه‌سازی ساختار پروژه:

refactor(folder-structure): reorganize components and services folders
  

۶. بهبود کارایی
- بهینه‌سازی عملکرد کوئری‌های دیتابیس:

perf(database): optimize query for retrieving large datasets
  

- کاهش زمان بارگذاری صفحات:

perf(page-load): lazy load images to improve page load time
  

۷. تست‌ها
- اضافه کردن تست‌های جدید برای تابع جستجو:

test(search): add unit tests for search functionality
  

- به‌روزرسانی تست‌های قدیمی:

test(cart): update tests to reflect changes in cart logic
  

۸. تغییرات جانبی و ابزارها
- به‌روزرسانی پکیج‌های pip:

chore(deps): update pip packages to latest versions
  

- تنظیم محیط توسعه برای استفاده از Docker:

chore(docker): add Dockerfile for local development
  

۹. یکپارچه‌سازی مداوم (CI)
- افزودن یک اسکریپت CI برای ساخت اتوماتیک پروژه:

ci: add CI script for automated builds
  

- رفع خطای پیکربندی در pipeline:

fix(ci): fix incorrect variable in CI pipeline

نکات مهم:
1. وضوح و شفافیت: پیام کامیت باید به وضوح تغییرات ایجاد شده را بیان کند. از عبارات گنگ یا نامفهوم پرهیز کنید
2. سازگاری با استانداردها: استفاده از کلمات کلیدی مانند feat، fix و... برای دسته‌بندی کامیت‌ها، کمک می‌کند تا تاریخچه تغییرات پروژه ساختاریافته و قابل پیگیری باشد
3. توضیحات کوتاه اما مفید: در پیام کامیت به‌خصوص در خط اول، تلاش کنید مختصر و مفید تغییرات را بیان کنید. در صورت نیاز، توضیحات اضافی می‌تواند در خطوط بعدی پیام کامیت اضافه شود

#git
#gitlab

@code_crafters

در DevOps، مفهوم "ناک" (NOC: Network Operations Center) به تیم یا مرکزی اشاره دارد که وظیفه نظارت، مدیریت و رفع مشکلات زیرساخت‌های شبکه و سرویس‌های یک سازمان را دارد. ناک‌ها به بررسی و پاسخ‌دهی به حوادث و رخدادهای مختلف در سیستم‌ها و شبکه‌ها می‌پردازند تا اطمینان حاصل شود که سرویس‌ها به درستی کار می‌کنند و در صورت بروز هرگونه مشکل، سریعاً حل می‌شوند.

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

1. ناک سطح 1 (L1 یا Frontline Support):
- این تیم اولین نقطه تماس برای مشکلات گزارش‌شده است.
- وظایف اصلی این سطح شامل نظارت بر سیستم‌ها و شبکه، بررسی اولیه مشکلات، و حل مسائل ساده و روزمره است.
- معمولاً مشکلاتی مانند ری‌استارت سرویس‌ها، بررسی لاگ‌های پایه، یا پیکربندی‌های ابتدایی در این سطح حل می‌شوند.
- اگر مشکلی در این سطح حل نشود، به سطح بعدی منتقل می‌شود.

2. ناک سطح 2 (L2 یا Advanced Support):
- این سطح با تخصص بیشتری در ارتباط با مشکلات فنی درگیر است.
- مشکلات پیچیده‌تر که نیاز به تجزیه و تحلیل بیشتر دارند (مانند بررسی عمقی لاگ‌ها، کار با ابزارهای پیشرفته‌تری مانند مانیتورینگ‌های پیچیده‌تر) به این تیم ارجاع داده می‌شود.
-در L2 همچنین ممکن است با مسائل زیرساختی یا تنظیمات شبکه‌ای پیچیده‌تر مانند مشکلات سرورهای مجازی یا کلاسترهای Kubernetes سر و کار داشته باشد.
- در صورت عدم توانایی حل مشکل در این سطح، مشکل به L3 ارجاع می‌شود.

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

4. ناک سطح 4 (L4 یا External Vendor Support):
- در برخی موارد نادر، مشکلات ممکن است خارج از کنترل داخلی سازمان باشد و نیاز به همکاری با تأمین‌کنندگان خارجی (مانند سرویس‌دهندگان ابری یا تولیدکنندگان نرم‌افزار) داشته باشد.
- این سطح به مواردی می‌پردازد که نیاز به پشتیبانی فنی از سوی شرکت‌های تأمین‌کننده یا شرکای تجاری دارند.

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

#devops
#k8s

@code_crafters

رمان فلسفی سقوط از آلبرکامو

کتاب یکی از شاهکارهای کامو در باب اگزیستانسیالیست و پوچگرایی به سبک کامو هستش(ذکر کنم که کتاب +۱۸ هستش)

موضوعیت کتاب در باب قضاوت کردن و تاثیر قضاوت شدن بر انسان در جامعه هستش و به سبک ادبی بینظیری نوشته شده (جای حرف برای گفتن زیاد داره نگم که اسپویل نشه)

در جایی از رمان اشاره به دختری داره که با پرت کردن خود به داخل یک رودخانه از روی پل، اقدام به خودکشی میکنه و در انتهای کتاب به شکل ظریفی کامو به این موضوع اشاره میکنه که اهمیت دادن به این قضاوت‌ها همچو پرت شدن آن دختر از پل به داخل رودخانه سرد و فریاد سر دادن بعد آن است


در انتهای هر آزادی حکم دادگاهی هست
برای همین است که بار آزادی بر دوش سنگینی میکند
مخصوصا هنگامی که تب داری یا در رنجی یا هیچکس را دوست نداری


#book

@code_crafters

یه سوال ساده از مهندس دوستم پرسیدم و رسیدیم به BCM

مخفف راهکار بازگشت از بحران در کسب و‌ کار هستش
نه کسب و کارهای کوچیک بلکه در سطح زیر ساختهای کور بانکینگ

و این دوتا برگ فقط اسامی و سربرگ موضوعاتی بود که برام تشریح کرد

خبر خوب اینکه سر فرصت قراره برامون راجبشون مقاله بزاره در کانال


#free

@code_crafters

در این سری پست میخوایم بررسی کنیم api gateway در معماری میکروسرویس چکاری میکند


یک api gateway در واقع یک ابزار مدیریت api هستش که بین یک کلاینت و یک مجموعه از سرویس‌هایی بکند قرار میگیره

در این حالت یک کلاینت یک‌ برنامه است که روی دیوایس‌های کاربران میشنه و سرویس‌های بکند در سرورهای قرار دارند

یک api gateway جزو یک برنامه تحویل است (ترکیبی از سرویس‌هایی که یک برنامه کاربردی در اختیار کاربران قرار میده) و شبیه یک پروکسی معکوس (revers proxy) عمل میکنه که همه درخواست‌ها api رو‌ می‌پذیره و پاسخ میده، تجمیعی از خدمات مختلف مورد نیاز برای برای انجام دادن و بازگشت نتایج مناسب

در یک شکل ساده تر api gateway یک بخش از نرم افزار است که رهگیری میکنه تماس apiهارو از یک کاربر و مسیردهی میکنه این رو به سرویس مناسب


چرا از api gateway استفاده میکنیم؟
بیشتر apiهای سازمانی از طریق api gateway مستقر میشوند. معمولا api gateway هندل میکنه وظایف که استفاده میشوند در سرتاسر یک سیستم از سرویس‌های api، مانند احراز هویت کاربران، محدودیت نرخ و آمار گیری

در حالت ابتدایی یک api سرویس میپذیره یک درخواست بیرونی و برمیگردون یک پاسخ رو، اما حیات اون انقدر ساده نیست، نگرانی‌ در یک مقیاس بزرگ رو‌در نظر بگیرید:

شما میخواهید از apiهای خود در برابر سواستفاده و استفاده زیاد محافظت کنید

شما میخواهید بدونید که مردم چقدر از api شما استفاده میکنن و ابزارهای مانتیورینگ و تحلیل اضافه کنید

اگر یک api تجاری دارید شما میخواهید به یک سیستم صورتحساب متصل شوید

ممکنه شما یک معماری میکروسرویس اتخاذ کرده باشید در این صورت یک درخواست میتواند به تماس ده‌ها برنامه مجزا نیاز داشته باشد

با گذشت زمان شما سرویس‌های جدیدی بالا میاورید و سرویس‌هایی رو بازنشسته میکنید (در مبحث soa اشاره کردیم قبلا) اما مشتریان میخواهند تمامی سرویس‌های شما را در یکجا داشته باشند

چالش ما ارائه یک تجربه ساده و قابل اعتماد در مقابل این همه پیچیدگی به مشتریان است. یک api gateway راهی برای جدا کردن رابط مشتری از apiهای پیاده سازی شده است. هنگامیکه یک‌کلاینت درخواستی میده api gateway اون رو به چندین درخواست تقسیم میکنه، و مسیردهی میکنه به مکان‌های مناسب، یک پاسخ رو تولید میکنه و همه چیز رو پیگیری میکنه


نقش api gateway در مدیریت api:
یک api gateway یک بخش از سیستم مدیریتی است، این api gateway رهگیری میکنه تمامی درخواستهای ورودی رو و از طریق سیستم مدیریت ارسال میکنه، و تمامی توابع مختلف ضروری رو انجام میده

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

کاهش تاخیر:

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

مدیریت ترافیک:

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

۱-سیاست‌های محدود کننده نرخ در یک بازه زمانی را مشخص میکند، برای هر کلاینت یا کلید، در برابر بار اضافی محافظت میکنند

۲-قواعد مهار درخواست،قوانین و محدودیت‌هایی را برای تنظیم ترافیک درخواست تعریف می‌کنند مانند: حداکثر نرخ‌های درخواست، مجوزهای انفجاری و سهمیه‌ها

۳-قواعد کنترل همزمانی بالاخص سقف تعداد درخواست‌های از ارتباط همزمان یا درخواست‌های که میتونن بصورت همزمان سرویس‌های بکند هندل کنند

۴-قواعد قطع مدار سلامت مانیتورینگ و پاسخگویی از سرورهای بکند و بلاک موقت یا تغییر مسیر ترافیک موقت، تا از خرابی عادی و ابشاری یا کندی سرویس‌ها جلوگیری کنید

۵-توزیع بار پویا از api gateway، بطور مداوم سلامت سرور را نظارت می‌کند و مسیریابی ترافیک را در زمان واقعی تنظیم می‌کند تا بتوانند افزایش تقاضا رو مدیریت کند، زمان پاسخ را حداقل و توان عملیاتی را به حداکثر برساند

استفاده از زیرساخت‌ها شبکه جهانی:

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

#api_gateway
#microservice



@code_crafters

هزینه اثربخشی:

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

۱-انعطاف پذیری:  apiهای http که عمومی‌ترند، می‌توانند از هر روش http استفاده کنند. که سادگی و انعطاف پذیری را در توسعه ارائه می‌دهند و کاهش هزینه می‌دهند rest api که به قواعد خاصی تمرکز و پایبند دارند ممکن است به تلاش و تخصص بیشتری نیاز داشته باشند جهت پیاده سازی و هزینه رو افزایش دهند

۲-زیرساخت: به دلیل انعطاف apiهای http ممکن است هزینه زیرساخت کمتری داشته باشند برای res api ها جهت پشتیبانی از از ویژگی‌ها نیاز به اجزای اضافی در زیرساخت یا خدمات اضافی باشد که به‌طور بالقوه باعث افزایش هزینه‌های زیرساخت شود

مقیاس پذیری: API های HTTP، که می توانند با افزودن سرورها یا نمونه های بیشتر به صورت افقی مقیاس شوند، ممکن است گزینه های مقیاس پذیری مقرون به صرفه تری را ارائه دهند، به ویژه در محیط های ابری با قابلیت های مقیاس خودکار. APIهای REST ممکن است به دلیل شرایط بدون حالت، حافظه پنهان، و ملاحظات معماری توزیع شده نیاز به مقیاس بندی پیچیده تری داشته باشند و ممکن است برای دستیابی به مقیاس پذیری افقی به منابع زیرساخت یا خدمات اضافی نیاز داشته باشند که به طور بالقوه هزینه ها را افزایش می دهد

#api_gateway
#microservice


@code_crafters

گمانه زنی: از اهداف تجاری تا اولویت بندی ویژگی‌ها

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

در فضای گمانه‌زنی چه سوالاتی مطرح میکنیم

۱- چگونه بدانیم یک ویژگی خاص به نفع سازمان است؟
۲-آیا نرم افزار تاثیر مثبت و قابل اندازه گیری برای کسب و کار داشته است؟
۳-آیا پروژه ما تفاوتی ایجاد خواهد کرد؟

گاهی اوقات یک برنامه خاص و یا ویژگی خاص به وضوح مزایای تجاری مورد انتظار از آن را ارائه نمیدهد و نباید پیاده سازی شود

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

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

برنامه ریزی استراتژیک در طول عمر یک پروژه بارها تکرار می‌شود

فعالیت‌ها شامل مدیران و ذینفعان و تیم‌هاست که ویژگی‌ها را ساخته و ارایه می‌دهند 

ذینفعان کسب و کار، با حمایت اعضای تیم تحویل، مهم ترین مشکلات کسب و کار را که نیاز به حل دارند و فرصت های امیدوارکننده برای کشف را شناسایی و بیان می کنند

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

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

توسعه مبتنی بر فرضیه یک مفهوم کلیدی در DevOps و روش استارتاپ ناب است در این رویکرد توسعه بعنوان مجموعه‌ای از آزمایش‌های کوچک برای اعتبارسنجی یا بی اعتبار کردن یک فرضیه در مورد حوزه مشکل پروژه در نظر گرفته میشود. این ازمایش‌ها کمک می‌کنند درک خود را از یک حوزه مشکل به تدریج و تدریجی افزایش دهیم

یک فرضیه یک عبارت ساده رو توصیف و چگونگی تایید آنرا مطرح می‌کند، یک نمونه ساده به این صورت است

We believe <some capability> will result in <some outcome>
We will know this to be true when <some measurable result is observed>

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

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

#BDD
#behavior_driven_development

@code_crafters

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


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

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

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

FOR <target customer>

WHO <needs something>

THE <product name> is a <product category>

THAT <key benefit, compelling reason to buy>

UNLIKE <primary competitive alternative>

OUR PRODUCT <statement of primary differentiation>

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

نوشتن یک بیانیه کار دشواری است اما در طول پروژه نتیجه می‌دهد، یک ایده بابت نوشتن بیانیه این است که تصور کنید در خال نوشتن یک آگهی محصول هستید بطور خلاصه:

محصول شما چه کاری انجام می‌دهد؟
چه سودی برای شرکت شما دارد؟
مخاطبان شما چه کسانی هستند و چرا باید نسبت به رقیبان از محصول شما استفاده کنند؟
نقاط اصلی اولیه فروش شما چیست؟

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

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

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

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

اگر نرم افزار اهداف تجاری را براورده کند(حتی اگر دامنه متفاوت از آن‌چیزی باشد که در ابتدا متصور می‌شد) از نظر طراحان کسب و کاری موفقیت آمیز تلقی می‌شود در غیر این صورت یک شکست در نظر گرفته می‌شود حتی اگر الزامات مشتریان را تا حد بالایی برآورده کند

#BDD
#behavior_driven_development

@code_crafters

نقشه‌ تاثیرات impact mapping:
یک راه حل ساده و سریع برای دستیابی به ویژگی ها و قابلیت‌هایی است که ارتباط مستقیمی با اهداف کسب و کار دارد. بر خلاف روش‌های سنتی و داستان کاربر user story که لیستی از ویژگی‌های از قبل آماده را به تیم توسعه می‌داد ، نقشه‌ تاثیرات از جلسات و گفتگو‌های مابین ذینفعان و کسب و کاران با تیم توسعه بوجود می‌آید، از هدف اصلی پروژه شروع خواهد کرد، چه کسانی را تحت تاثیر قرار خواهد داد تا کشف ویژگی‌های تجاری قابل پیاده سازی شده در تصویر اول در کامنت‌ها مشاهده یک نمونه از اون رو برای برنامه سفرهای هوایی میبینید

پنج سوال متفاوت اما مرتبط باهم:

۱ـ نقطه درد: ما چرا اینکار را انجام می‌دهیم؟ کدام مشکل کسب و کار را حل میکنیم و چگونه باید آن را اندازه گیری کنیم؟
۲ـ هدف: ما چکاری برای آن انجام میدهیم؟ هدف ما جهت بهبود چیست و چه مقدار؟
۳- بازیگر: افراد کلیدی که با سیستم ما در تعامل هستند چه کسانی هستند و رفتار آنها به اهداف ما کمک می‌کند یا مانع آن می شود؟
۴ـ تاثیر: چگونه می‌توانیم به این بازیگران کمک یا تشویق کنیم تا به ما در رسیدن به اهدافمان کمک کنند؟ چه تغییراتی در رفتار می‌خواهیم ببینیم؟
۵ـ تحویل: چه ویژگی های برنامه ممکن است از این تغییرات در رفتار پشتیبانی کند؟ ما به عنوان یک تیم تحویل چه کاری می توانیم انجام دهیم تا به تاثیری که به دنبال آن هستیم دست پیدا کنیم؟

نقطه درد pain point به مسیله یا چالشی میگوییم که کسب و کار برای آن طراحی یا توسعه داده میشود

شناسایی نقطه درد:
اولین سوالی که باید پاسخ دهید "چرا (چرایی)" ساخت یک نرم افزار است. چه مشکلی رو حل میکنید؟ و چه مقدار میتواند تفاوت ایجاد کنید؟
دانستن این موضوع در طراحی نقشه تاثیرات تاثیرگذار است

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

چه کسی سود خواهد برد؟ تعریف بازیگران (بخش actor در تصویر اول)
"چه کسی" سوال بعدی ما است، بازیگرانی که با سیستم ما در تعامل هستند چه کسانی هستند؟ ذینفعان پروژه چه کسانی هستند؟ نتایج به سود چه کسانی است؟ چه کسانی از برنامه ما استفاده میکنند؟ چه کسانی مانع رشد پروژه و رقیب ما هستند؟
هدف تمامی پروژه‌ها رساندن سود به نفع سازمان است و درون سازمان افرادی هستند که از نتایج پروژه متاثر میشوند، این افراد ذینفعان و بازیگران هستند، در نهایت ممکن است که پروژه یک عملکرد مثبت داشته باشد اما سود فردی آن مفید نباشد(برای مثال گرفتن وام بانکی و ایجاد قوانین سخت گیرانه که تاثیر در سود بانکداری و رنج وام گیرنده در بازپس دهی میشود، اما با تلاش برای به حداقل رساندن ریسک وام گیرنده‌های پرهطر نتایج مفیدی برای بانک داری خواهد داشت)

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

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


چگونه رفتار ذینفعان را تغییر دهیم؟ تعریف تاثیرات (بخش impact در تصویر اول)
سوال بعدی که باید بپرسید «چگونه» است، ذینفعان و کاربران چگونه در دسترسی به اهداف تجاری کمک می‌کنند؟ چگونه رفتار و فعالیت آنها تغییر کند تا به ما در رسیدن به نقاط درد کمک کند، بعنوان مثال اگر کاربر هستند چگونه میتوانیم انجام کار را برای آنها آسان‌تر کنیم؟ اگر مشتری هستند چگونه کاری کنیم که ما رو به رقبا ترجیح بدهند؟ از طرف دیگر رفتار آنها چگونه ممکن است موجب شکست پروژه گردد؟؟
شما به تاثیری که بر رفتار کاربر می‌گذارید فکر می‌کنید، چگونه سیستم مشارکت ذینفعان در اهداف تجاری را آسان‌تر می‌کند، یا چگونه بر رفتار انها تاثیر گذاشته و آنها را به روش‌های دیگر تشویق کنید تا اینکار را انجام دهید، شما مسائلی رو از دیدگاه ذینفعان مطرح می‌کنید که نشان دهد نرم افزاری می‌سازید که رویکرد انجام کار را تغییر و به روشی مثبتی مطابق با اهداف کسب و کار انجام دهد

#BDD
#behavior_driven_development

@code_crafters

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

ترسیم نقشه تاثیرات impact mapping به شما کمک میکند تا ویژگی‌های جدید را با یک هدف تجاری تجسم کنید و کمکی به تایید بر فرضیاتی که ممکن است انجام دهید، علاوه براین فرضیات نقشه‌ تاثیرات از شما میخواهد پارامترهای سنجش نهایی را نیز تعریف کنید،توجه داشته باشید که این یک برنامه نیست بلکه اسناد زنده و تکراری هستند که در تجسم مفروضات و ایجاد روابط بین ویژگی‌ها و اهداف تجاری کمک میکنند


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

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

پارامترهای ارزیابی راهبردی:
پنج معیار وجود دار که هر استارتاپی برای موفقیت باید آنها رعایت کند در غیر اینصورت با شکست خواهد خورد تصویر اول در کامنت‌ها

۱- اکتساب

اشاره به جذب بازیگران دارد از طریق ارائه خدمات کوچک رایگان اما واقعی در دسترس
اما این تنها به مشتریان و کاربران اشاره ندارد 
برای مثال یک سیستم بانکی را در نظر بگیرید علاوه بر نگه داشت مشتریان و ارتباط پایدار با آنها باید این موضوع با سرمایه گذاران و سایر ارائه دهندگان سیستم‌های دیگر نیز باشد

۲- فعال سازی

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

۳ـ حفظ

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

۴ـ ارجاع

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

۵ـ بازگشت

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

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

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

#BDD
#behavior_driven_development

@code_crafters

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

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

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

نویسنده کتاب بابت جا افتادن موضوع یک مکالمه طولانی طرح کرده که خلاصه اون رو میگم😅

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

ساخت منظره حماسی (epics -مجموعی از چند داستان کاربری-)
طراحی راهبردی فقط با هدف برجسته کردن مشکلات نیست. مهم‌تر از آن، به تیم‌ها کمک می‌کند تا مکالمات مؤثرتری در مورد تأثیری که می‌خواهند داشته باشند، و در مورد اینکه چه دستاوردهای سطح بالایی برای ایجاد این تأثیر باید ارائه کنند، داشته باشند. این موارد قابل تحویل سطح بالا اغلب به عنوان Epics نامیده می شوند، و ما این دیدگاه وسعت اول از حماسه ها را که می خواهیم ارائه دهیم یک منظره حماسی می نامیم - تصویری گسترده از قابلیت هایی که باید ارائه دهیم

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

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

#BDD
#behavior_driven_development

@code_crafters