از جان مهندسین نرم افزار چه میخواهند؟؟


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

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

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

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

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


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


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

#BDD
#behavior_driven_development

@code_crafters

ساخت نرم افزاری که تفاوت ایجاد کند

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

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

بیایید با یک مثال پیش برویم:
رییس یک سازمان میخواهد به نرم افزار حساب داری خود یک ویژگی را اضافه کند، او مراحل زیر را در پی خواهد گرفت

۱- او به تحلیلگر کسب و کار خود میگوید چه ویژگی را لازم دارد 

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

۳- توسعه دهنده مستندات را گرفته و آنرا تبدیل به کد میکند

۴ـ تستر مستندات را خوانده و آزمایشات خود را جهت تایید آنچه در سند نوشته شده است را انجام میدهد

۵- خروجی کار همراه کدها توسط توسعه دهنده مستند میشود

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

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

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

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

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

۴- هنگامی که ازمونهای خودکار به درستی اجرا شوند تیم‌شواهد مشخصی دارد که آنچه در مرحله ۲ ذکر شده، صورت گرفته است 

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

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

۱- عدم ساختن نرم افزار درست (انواع بگ‌ها و مشکلات)
۲- عدم ساختن درست نرم افزار (غیر قابل استفاده برای کاربران)

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

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

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

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


#BDD
#behavior_driven_development


@code_crafters

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

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

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


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

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

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

یک ضرب‌المثل سوئیسی میگه

وقتی زمین با نقشه مخالف است، به زمین اعتماد کنید

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

در نهایت لازم است بدانید که BDD یک متدلوژی اجایل نیست بلکه یک شیوه دستیابی به تفکراتی است که به شما کمک خواهد کرد تا ویژگی‌های اصلی را بشناسید و از غیرمفروضات دوری کنید، با متدلوژی‌های اسکرام و کانبان بشدت دوست است، برای مثال BDD در جلسات اصلاح بک‌لاگ اسکرام حضور خواهد داشت و موجب افزایش سرعت شما و تیم شما میشود


#BDD
#behavior_driven_development


@code_crafters

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

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

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

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

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

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

مثال‌ها نقش اصلی را در BDD بازی میکنند و به همه کمک می‌کنند تا نیازمندی‌ها را واضحتر درک کنند

اصول و شیوه‌های BDD با استفاده از ابزارهای اختصاصی BDD مانند Cucumber و specflow خودکار می‌شوند. به این ترتیب هم نیازها مستند میشود هم تست‌های خودکار اجرا میشود

نیازهای gherking به زبان انگلیسی ساده، اما با ساختاری خاص بیان میشود، هر سناریو از تعدادی مرحله تشکیل شده است، جایی که هر مرحله با یکی از تعداد کمی از کلمات کلیدی (Given, When, Then, And, But) شروع میشود

ترتیب طبیعی بدین شکل است:
Given ... When ... Then

Given (پیش شرط‌های سناریو را شرح میدهد و محیط آزمون را آماده میکند)

When (عمل تحت آزمایش را توصیف میکند)

Then (نتایج مورد انظار را شرح میدهد)

از and و but برای پیوستن بین چند مرحله بالا استفاده می‌شود

Feature: Transferring money between accounts
   In order to manage my money
   As a bank client  I want to transfer
   Scenario: Transferring money ...
       Given Tess has a current account with $1000  
       And a savings account with $2000.00  
       When she transfers $500 from current to savings  
       Then she should have $500 in her current account  
       And she should have $2500 in her savings account

#BDD
#behavior_driven_development


@code_crafters

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

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

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

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

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

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

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

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

کاهش هزینه:
با حذف ویژگی‌های غیر تجاری و غیر کاربری موجب افزایش تمرکز بر روی کد و ویژگی‌های تجاری خواهد شد که در نهایت موجب افزایش کیفیت کد (ساخت صحیح نرم افزار) و کاهش باگ و هزینه نگهداری و دیباگ میشود

#BDD
#behavior_driven_development


@code_crafters

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

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

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

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

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

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


#BDD
#behavior_driven_development


@code_crafters

تور گردباد توسعه رفتار محور

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

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

۱ـ حدس و گمان speculate:
در این مرحله تیم بابت شناخت و درک اهداف تجاری سطح بالا و شناسایی ویژگی‌هایی که به ما در شناخت آن کمک میکند وارد گفتگو با افراد افراد کسب و کار میشود

۲- توصیف کردن illustrate:
در این مرحله افراد تیم دانش عمیقی مخصوص به آن ویژگی‌ می‌سازند و این از طریق مکالمات در مورد بتن مثال‌های از قواعد تجاری و داستان کاربر (user story) می‌باشد

داستان کاربر یک ابزار از متدلوژی چابک agile است (چیزی که کاربر نیاز دارد در پروژه باشد-ویژگی را از دیدگاه کاربر نظاره گر باشد)

۳-فرموله کردن Formulate:
جایی که اعضای تیم نمونه های کلیدی را به مشخصات اجرایی (در بخش قبلی به اهمیت آن و نحوه مصرف به تفصیل سخن گفتیم) تبدیل می کنند، با استفاده از نمادی که هم برای افراد تجاری قابل خواندن است و هم می تواند به عنوان آزمایش خودکار اجرا شود

۴-خودکار کردن automate:
جایی که توسعه‌دهندگان و آزمایش‌کنندگان این مشخصات اجرایی را به تست‌های پذیرش خودکار تبدیل می‌کنند و از این تست‌های پذیرش خودکار برای هدایت فرآیند توسعه استفاده می‌کنند

۵-نشان دادن demonstrate:
جایی که گذراندن آزمون‌های پذیرش خودکار به عنوان مدرکی مبنی بر اینکه یک ویژگی به درستی پیاده‌سازی شده است و به عنوان مستنداتی که ویژگی‌های فعلی و نحوه کار آنها را نشان می‌دهد عمل می‌کند. اینجاست که تیم تأیید می‌کند که یک ویژگی آنچه از آن خواسته شده است را انجام می‌دهد

۶-اعتبارسنجی validate:
جایی که تیم و کسب‌وکار می‌بینند که ویژگی‌ها در دنیای واقعی چگونه عمل می‌کنند و آیا ارزش تجاری را که وعده داده بودند ارائه می‌دهند یا خیر

تصویر اول در کامنت

بیایید با یک مثال عملی آنچه در بالا بیان شد را یاد بگیریم

۱-گمانه زنی-شناسایی ارزش و مقادیر کسب و کار:
تصور کنید در یک شرکت از ما خواسته شده تا یک تیم کوچک رو مدیریت کنیم که بر روی یک شبکه ریلی(قطار) بزرگ برنامه‌ای نوشته بشه که ساعات حرکت، توقف، دیرکرد و ... رو شامل بشه

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


#BDD
#behavior_driven_development


@code_crafters

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

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

#BDD
#behavior_driven_development


@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