در پروژه‌های نرم‌افزاری، مدیریت و نگهداری کد منبع یکی از بخش‌های مهم توسعه هستش، ما از ابزارهای متعددی برای این منظور استفاده می‌کنیم، مثه 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

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

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

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

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


#BDD
#behavior_driven_development

@code_crafters

توصیف و اولویت بندی ویژگی‌ها

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

در این بخش میخواهیم نحوه ارائه قابلیت‌هایی که بوسیله نقشه‌ تاثیرات و طراحی راهبردی پیدا کردیم گفتگو کنیم، ما یاد میگیریم چگونه ویژگی‌های سطح بالای نقشه‌ تاثیرات و منظره حماسی را به داستان کاربری (user story) بشکنیم، چگونه این ویژگی‌ها را توصیف و اولویت بندی کنیم و چیزهایی که یاد میگیریم در طی برنامه‌ریزیی اسپرینت‌ها به ما کمک خواهد کرد

اسپرینت: یک بازه زمانی مابین دو تا چهار هفته که در طی این مدت تیم توسعه سعی در اتمام و تحویل و اتمام user story را دارد

داستان کاربر: یک واحد کوچک از رویکرد اجایل است که یک هدف را از زبان کاربر نهایی یا مشتری بیان میکند (ویژگی نیست)

برخی از موضوعات مورد بررسی:

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

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

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

رویکرد BDD و اصلاح بک لاگ(backlog):

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

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

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

برای تیم BDD بک‌لاگ محصول شامل ویژگی‌هایی است که در بخش قبلی بوسیله نقشه تاثیرات و طراحی راهبردی کشف شد

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

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

ویژگی چیست:
در تیم اجایل برای توصیف چیزی که میسازند از کلمات بسیار متفاوتی استفاده می‌کنند
(Epics, capabilities, themes, requirements, features, use cases, User Stories, tasks)

در متدلوژی‌ها و تیم‌های مختلف مفهوم جدایی برای هر کلمه بکار میبرند اگرچه در اجایل و اسکرام کلمات user story, epics,theme حضور طولانی دارند، در بسیاری از تیم‌ها همچنان ساعت‌های طولانی را صرف مفهوم کلمات می‌کنند تا صرف انرژی برای توسعه سیستم

ما میخواهیم آنچه هست را با زبانی مطرح کنیم که کاربران نهایی متوجه آن بشوند و ذینفعان سریع درک‌کرده و بازخورد به ما بدهند

#BDD
#behavior_driven_development

@code_craftets

ما میخواهیم دو کار انجام دهیم:

ارائه ارزش ملموس و قابل مشاهده به کسب و کار در فواصل زمانی منظم
دریافت بازخورد منظم تا بدانیم آیا در مسیر درست حرکت می کنیم

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

بخاطر سادگی و سازماندهی در ادامه مباحث ما از چهار اصطلاح استفاده میکنیم: قابلیت، ویژگی، داستان کاربر و مثال (تصویر اول در کامنت)

یک نگاهی اجمالی به مفاهیم:

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

ویژگی ها عملکرد نرم افزاری را نشان می دهند که شما برای پشتیبانی از این قابلیت ها می سازید.  "رزرو آنلاین پرواز" یک ویژگی است

وقتی این ویژگی‌ها را می‌سازید و ارائه می‌دهید، می‌توانید از User Stories برای تقسیم کار به بخش‌های قابل مدیریت‌تر و برنامه‌ریزی و سازماندهی کار خود استفاده کنید

می‌توانید از مثال‌هایی برای درک اینکه این ویژگی‌ها چگونه به کاربران شما کمک می‌کنند و برای هدایت کارتان در داستان‌های کاربر استفاده کنید. می‌توانید از مثال‌هایی برای درک ویژگی‌ها و داستان‌های کاربر استفاده کنید

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

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

همچنین می‌توانید بررسی کنید این ویژگی به نفع کدام ذینفعان است این به شما کمک می‌کند از دید آنها به ویژگی نگاه کنید تصویر دوم در کامنت

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

در بخش بازگشت مشتریان این درخواست مدیر فروش است و باید او را راضی کنید و دیدگاه او را در نظر بگیرید و ویژگی شما باید کاربران را برای بازگشت ترغیب کند تصویر چهارم در کامنت ما در BDD از این فرمت قدیمی و جا افتادن
(As a ... I want ... So that)
استفاده میکنیم که میتونه تمرکز کنه روی مقادیر تجاری و قابلیت‌هایی که یک ویژگی میتونه ارائه بده همچنین شما می‌توانید از فرمت
(In order to ... As a ... I want)
که روی مقادیر تجاری متمرکز شود افراد با تجربه روی هر دو فرمت میتوانند تعاریف با کیفیت و معناداری بسازند. در نهایت هیچ قالب استاندارد و ویژه‌ای وجود ندارد تیم می‌تواند روی نوع فرمت به توافق برسد

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


#BDD
#behavior_driven_development

@code_crafters

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

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

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

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

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

ویژگی‌ها می‌توانند با یک یا چند داستان کاربری توضیح داده شوند:
داستان‌های کاربری نون و کره پروژه‌های اجایل هستند و از پیدایش اجایل به شکل‌های اندک متفاوت وجود داشته‌اند. یک داستان کاربر توضیح مختصری از چیزهاییست که ذینفعان و کاربران می‌خواهند بدست بیاورند و به زبانی قابل فهم برای کسب و کار بیان شده است. یک نمونه ساده از آن میتواند مانند مثالهای قبلی (cherking) با همان ساختار
(in story: ... As a ... I want ...)
باشد، یا به شکل کارت‌هایی باشد که توضیحات بیشتری را شامل شود مانند تخمین زمان بر حسب ساعت یا مفهومی انتزاعی‌تر(ویژگی‌ها را نیز میتوان به همین شکل نوشت) تصویر دوم در کامنت در آن طرف کارت می‌توانید لیستی از معیارهای قابل پذیرش را یادداشت کنید که مرزهای داستان را مشخص کنند البته این معیارها کامل نیستند و نمی‌توان از مالک پروژه و ذینفعان انتظار داشت در بدو کشف ویژگی تمام الزامات را مطرح کنند، اما به مرور زمان با افزایش دانش نسبت به ویژگی می‌توان آن را کاملتر کرد و بعنوان اسناد پروژه هم نگه داشت، این موجب می‌شود که درک ما شفاف‌تر و واضحتر گردد تصویر سوم در کامنت
داستان کاربری شبیه یک ویژگی است اما تمایل به سطح پایین‌تر دارد، یک داستان کاربری لازم نیست بصورت مجزا قابل تحویل باشد اما میتواند روی یک جزئ از ویژگی تمرکز کند، داستان کاربر می‌تواند به ما در طراحی و سازماندهی تحویل یک ویژگی و ارائه راه حل مناسب کمک کند

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

یک نکته مفید دیگر این است که داستان کاربری می‌تواند الزامات بیشتر را به تعویق بیاندازد تا با گذر زمان درک شما از سیستم بیشتر و بهتر گردد اگر داستان کاربر در ابتدا کامل بسته شود ممکن است الزامات مهمی را فراموش کنید و هیچوقت رضایت ذینفعان را کسب نکنید

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

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

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




#BDD
#behavior_driven_development


@code_craftets

اما تمایز بین این دو حائز اهمیت است

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

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

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

داستان کاربری از مصنوعات برنامه ریزی هستند که به شما کمک می‌کنند تا بدانید چه کارهایی به مراتب باید انجام دهید تا یک ویژگی را تحویل دهید

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

ویژگی‌های انتشار و ویژگی‌های محصول
یک قابلیت چیزی است که به کاربران نهایی برای دستیابی به اهداف تجاری کمک می‌کند و در تیم BDD یک ویژگی بخشی از یک عملکرد است که از یک قابلیت حمایت می‌کند. اما در برخی از مقیاس‌های متدلوژی اجایل مانند (XSCALE, SAFe, LeSS ) کلمه ویژگی با اندکی تفاوت استفاده میشود در این متدلوژی‌ها ویژگی، عملکرد جدید
یا اصلاح شده را توصیف می‌کنند، نه رفتار سیستم بطور مطلق (برای وضوح بیشتر «ویژگی انتشار» می‌نامیم)

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

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

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

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

کاربرد این اصل برای توسعه نرم افزار است که توسط «کریس متس» ابداع شده است کریس اصول گزینه های واقعی را در سه نکته ساده خلاصه می کند:
۱- گزینه ها ارزش دارند
۲- گزینه ها منقضی می شوند
۳- هرگز زود تعهد نکنید مگر اینکه دلیل آن را بدانید

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

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

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

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

#BDD
#behavior_driven_development


@code_crafters

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

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

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

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

کشف عمدی به شما کمک می‌کند تا این اطلاعات را بدست آورید

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

#BDD
#behavior_driven_development

@code_crafters

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

انتشار و برنامه ریزی زمان بندی BDD
این دو اصل به ما میگویند که برنامه ریزی با جزئیات خیلی قبلتر از زمان واقعی چقدر بیهوده است ابتدا یک برنامه بلند مدت را اتخاذ کنید و بعدها برنامه حماسه و چشم انداز را مشخص کنید بیایید ببینیم در دو مرحله حدس و گمان و مصور سازی این دو اصل چگونه به ما کمک میکنند تصویر اول در کامنت‌ها

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

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

#BDD
#behavior_driven_development

@code_crsfters

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

کتاب «در باب حکمت زندگی» یکی از آثار بشدت معروف اوست (شاید همان کتابی باشد که بسیاری بدنبال آن هستید که با زبانی ساده در خصوص شما و زندگی بدون پرده سخن بگوید) که در طی آن سعی بر شناخت و توضیح حالات رفتاری و روانی انسان دارد در طی کتاب ممکن است مقصود حرف‌های او را خود ندانید اما باید بگویم که بسیاری از بخش‌های کتاب را باید به خود بگیرید نه دیگران در این کتاب به مسائلی پرداخته که بخش عمده زندگی شما را در بر میگیرد


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

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

متودوروس

#book

@code_crafters