وب سایت کانال https://codecrafters.ir

لیست هشتک‌ها در کانال رو در زیر براتون خواهم گذاشت و آپدیت خواهد شد


#design_patterns الگوهای طراحی

#postgresql پستگرس

#k8s کوبرنتیز

#agile اجایل
#scrum

#algorithm الگوریتم

#video

#meeting متینگ‌

#principles اصول کدنویسی

#project_managment_system مدیریت تیم

#free خارج از مبحث کامپیوتر


#app برنامه‌های کاربردی

#Git #actions مباحث مربوط به گیت و گیتلب

#conda #env کار با

#Docker مباحث مربوط به داکر

#AI #ML مباحث هوش مصنوعی

#book معرفی کتاب

#monitoring بررسی وضعیت سیستم و کد

#concurrency همزمانی کتاب grokking concurrency


#blovkchain #web3

#DDD #domain_driven_design

#BDD #behavior_driven_development

#soa #sso #microservice


@Code_Crafters

Git Hub:
https://github.com/CodeCrafters-ir/

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


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

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

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

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

در این سری از پست‌ها میخواهیم راجب 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