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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#BDD
#behavior_driven_development

@code_craftets

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


#BDD
#behavior_driven_development

@code_crafters

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

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

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

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

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

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

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

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

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

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

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




#BDD
#behavior_driven_development


@code_craftets

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#BDD
#behavior_driven_development


@code_crafters

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

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

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

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

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

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

#BDD
#behavior_driven_development

@code_crafters

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

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

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

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

#BDD
#behavior_driven_development

@code_crsfters

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

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


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

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

متودوروس

#book

@code_crafters

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

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

کار در قالب تکرارها (iteration) کوتاه مدت و زمان ثابت (timeboxed) صورت میگیرد که یک هفته/ماه طول می‌کشد که در هر تکرار تیمی چندتخصصی (cross-functional)، خود سازمانده، همه کارهای طراحی،اجرا و تست را انجام میدهند. این چرخه و رویکرد الزامیست تا در نهایت ویژگی درستی که ارزش داشته تولید و در محصول جا داده شود. معمولا حجم کار در بک‌لاگ فراتر از توان انجام تیم توسعه قرار دارد که در یک تکرار انجام شود. بنابراین در ابتدای هر تکرار در خصوص اولویت بندی اقلام موجود در بک‌لاگ محصول تصمیم گیری می‌شود. پس از اتمام هر تکرار ویژگی‌های اتمام شده به ذینفعان نشان داده شده تا نظر خود را مطرح کنند و در تکرار بعدی تیم روش انجام آن را تغییر دهد. اگر اقلام جدیدی کشف گردد مالک محصول (product owner/po) اقلام را به بک‌لاگ محصول اضافه می‌کند تا در تکرار بعدی انجام شود.

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

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

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

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

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

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


#scrum

@code_crafters

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

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

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

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

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

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

۱- جریان مار در سیستم را تصویر سازی کنید
۲- هیچ کاری بیشتر از ظرفیت موجود صورت نگرفته
۳- برای ایجاد بهبود مستمر سیستم جریان کار را اندازه گیری کنید

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


#scrum

@code_crafters

یه خبر خوب بهتون بدم

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

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

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

کل کار بر روی api هستش و درگیر تمپلیت و ... نمیشید


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

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

#sso

@code_crafters

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

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

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

مالک محصول

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

استاد اسکرام

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

تیم توسعه

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

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

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

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

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


#scrum

@code_crafters

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

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

اندازه هر قلم از اقلام موجود در بک‌لاگ برابر با هزینه انجام آن است که مالک محصول جهت اولویت‌بندی (مرتب سازی/سازماندهی) بک لاگ درست، لازم است آن را بداند. اسکرام برای اندازه کیری اقلام روشی را اجبار نمی‌کند اما در بسیاری از تیم‌ها از واحدهای نسبی مانند «امتیاز داستان» یا «روز ایده‌آل» استفاده می‌کنند. در این روش‌ها فقط به نسبت اندازه یک قلم به سایر قلم‌ها توجه می‌کنند


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

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

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

اسکرام روزانه:
جلسه اسکرام روزانه هر روز از اسپرینت و در یک بازه زمانی مشخص (ابتدای روزکاری/انتهای روز کاری) و بمدت حداکثر ۱۵ دقیقه انجام می‌دهند. این جلسات کوتاه و ایستاده صورت میگیرد که به آن «جلسه ایستاده روزانه» می‌گویند تصویر چهارم در کامنت

این جلسه بین اعضای تیم جهت اطلاع و با کمک استاد به سه پرسش پاسخ میدهند:

چه کارهای در روز انجام داده‌اید؟
چه کارهایی در روز میخواهید انجام دهید؟
چه مشکلات و موانعی جلوی پیشرفت من را گرفته؟

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

#scrum

@code_crafters

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

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

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

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

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

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


#scrum

@code_crafters

«مرگ، خود نابودکننده است اما اندیشه‌ی به مرگ نجات‌بخش»

اما چطور و چگونه؟ اینجــا
بشنوید

این عبارت را یالوم از هســتی و زمــانِ مارتین #هایــدگر گرفته است.

اصول چابکی

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

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

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

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

-پذیرش تغییرپذیری سودمند است
-از توسعه تکراری و تدریجی استفاده کنید
-به کمک بازرسی،تطبیق و شفافیت از تغییرپذیری استفاده کنید
-انواع عدم قطعیت را همزمان کاهش دهید

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

استفاده از توسعه تکراری و تدریجی:
در توسعه برنامه محور و ترتیبی، فرض بر درست بودن و زود فهمیدن همه چیز است که در پایان کنار هم قرار میگیرند.اما اسکرام مبتنی بر توسعه تکراری و تدریجی است، توسعه تکراری و تدریجی دو مفهوم جدا از هم هستند

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

اسکرام برای ترکیب این دو از اسپرینت استفاده میکند تا از این طریق بر ضعف هردو فائق آید.تصویر سوم در کامنت

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

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

@code_crafters

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

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

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

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

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

پیش‌بینی و تطبیق:
در اسکرام دائما بین پیش‌بینی و تطبیق در حال برقراری تعادل هستیم، که پنج اصل دارد:

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

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

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

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

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

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

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

#scrum

@code_crafters

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

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

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

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

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

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

کار در جریان:
کاری که شروع شده و اتمام نیافته است.در توسعه محصول باید مارهای در جریان رو شناسایی و به درستی مدیریت کنیم.چهار اصل آن

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

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

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

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

#scrum

@code_crafters

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

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

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

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

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

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

کارایی:
در اسکرام سه اصل برای کارایی وجود دارد:

-سریع حرکت کنید اما عجله نکنید
-با کیفیت بسازید
-تشریفات کمینه و کافی داشته باشید

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

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

تشریفات کمینه و کافی:
رویکرد برنامه محور به رویکرد پرتشریفات، مستندمحور، سنگین گرایش دارند.در حالیکه بسیاری از این تشریفات نیازی به رسمیت ندارند با این خال تمام این تشریفات بد نیست. اما اسکرام تایید کمی بر تشریفات فرآیندی دارد. چند نمونه تشریفات غیر ضروری:

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

#scrum

@code_crafters

هدف ما در اسکرام حذف رسمیت غیر ضروری است بنابراین سطح تشریفات پایین نگه داشته می‌شود که این وابسته به سازمان و محصول آن است. تصویر اول در کامنت

اسکرام مخالف مستندسازی نیست اما مستندات قفسه‌ای را نمی‌پسندد. نمونه‌های زیر مستندات ارزشمند هستند:

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

برای دوستان بکند:

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

در نهایت هر آنچیزی که به افزایش دانش سریع دیگران کمک کند

#scrum

@code_crafters

در جایی از کتاب که شوپنهاور بشکل رادیکال شدید آنچه هست انسان رو واکاوی میکنه موضوع جالبی را مطرح میکند

«شخصیت انسان هیچگاه تغییر نمیکند»

شوپنهاور دو موضوع را پیش میکشد
جهان عینی و جهان ذهنی

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

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

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

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

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

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


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


#free

@Code_Crafters