کتاب 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

اسپرینت
اسکرام، کارها را در قالب تکرارهایی با نام اسپرینت سازماندهی می‌کند

مرور
اسپرینت اسکلت‌بندی چارچوب اسکرام است تصویر اول در کامنت

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

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

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

۲-اولویت‌دهی اجباری:
زمان ثابت ما را مجبور به اولویت‌بندی کارها می‌کند و بخش مهم آن را ابتدا انجام دهیم که موجب تمرکز ما بر روی انجام سریع کارهای ارزشمند می‌شود 

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

۴-دوری از کمالگرایی غیر ضروری:
زمان ثابت موجب می‌شود تا از صرف زمان زیاد جهت یک ویژگی خیلی خوب صرف نظر کنیم در حالیکه ویژگی خوب هم کافیست 

۵-انگیزه اتمام کار:
زمان ثابت انگیزه ایجاد می‌کند با این تصور که زمان مشخصی برای اتمام وجود دارد تیم را وادار میکند با سخت کوشی کارها را سروقت انجام دهد

۶-بهبوددقابلیت پیش بینی:
زمان ثابت قابلیت پیش بینی حداقل برای اسپرینت بعدی را ایجاد می‌کند

کوتاه مدت:
کوتاه بودن مدت اسپرینت مزایای فراوانی دارد:

۱-سهولت در برنامه‌ریزی:
کوتاه مدت سهولت برنامه ریزی را آسانتر می‌کند 

۲-بازخورد سریع:
در کوتاه مدت بازخورد سریعتر ایجاد می‌شود که موحب می‌شود از تصمیمات اشتباهی که تصمیمات اشتباه دیگری را منجر می‌شود جلوگیری کرد و مسیرهای نامطلوب را بازنگری کرد

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

۴-محدود کردن اشتباه:
اصرار بر کوتاه مدت بودن دریافت بازخورد است تا حداقل و در نهایت دو هفته در اشتباه باشیم 

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

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

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

-زمانیکه بخواهد بابت دریافت بازخوردهای بیشتر اسپرینت‌ها را کوتاه‌تر کند. که بصورت ازمایشی چند اسپرینت کوتاه‌تر می‌شود (چهار هفته به دو هفته)

-تعطیلات سال نو یا سال مالی جهت طولانی‌تر کردن اسپرینت‌ها (دو هفته به سه هفته)

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

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

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


#scrum

@code_crafters

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

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

تغییر ناپذیری هدف اسپرینت:
پس از آغاز اسپرینت تغییر هدفی که منجر به تاثیر قابل توجهی بر هدف اسپرینت داشته باشد مجاز نیست

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

-تعهد دو جانبه:
هدف زیربنایی جهت تعهد تیم با مالک است. تیم متعهد به تحقق هدف و مالک متعهد به عدم تغییر هدف است

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

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

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

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

در مواقع چند تیمی گزینه دو و سه مناسب‌تر هستند

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

که اقلام آن به متغییرهای زیر وابسته است:

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

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

#scrum

@code_crafters

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

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

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

#scrum

@code_crafters

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

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

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

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

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

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

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

روش ساده استفاده از آن رویکرد سه C است

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

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

#scrum

@code_crafters

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

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

معیارهای INVEST:
شش معیار برای ارزیابی مناسب بودن داستان‌ها

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

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

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

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

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

#scrum

@code_crafters

آزمون پذیری:
داستان یا قابل آزمایش است یا نیست، یا تماما قبول می‌شوند یا در رد سدن یکی به معنای رد کامل است. نیازی به آزمون همه داستان‌ها نیست یا برخی امکان پذیر نیست، برای مثال در یک اپیک آزمایشی برای آن نیست یا لازم نیست (اپیک برای ساخت شکسته می‌شود)

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

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

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

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

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

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

#scrum

@code_crafters

بک‌لاگ محصول

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


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

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

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

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

۳-برآورد شده:
اندازه هر قلم از بک‌لاگ متناسب با حجم کار لازم برای توسعه آن است که مالک از آن بعنوان یک معیار جهت اولویت بندی استفاده می‌کند. اقلام بزرگ در بالای اولویت بندی به مالک میگوید که باید شکسته شوند تا وارد اسپرینت گردد. اقلام بالای بک‌لاگ کوچکتر و حزییات بیشتری دارند و زمان برآورد شده انها نیز دقیق‌تر است (اقلام بر اساس «امتیاز داستان» یا «روز ایده‌آل» براورد می‌شوند)، اقلام بزرگتر در پایین بک‌لاگ براورد نمی‌شوند یا از سایز (XXL, XL, L) برای برآورد آن استفاده می‌کنند 

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

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

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

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

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

#scrum

@code_crafters