اصول چابکی

اصول هدایت کننده سازوکارها هستند. در این بخش اسکرام را با سه رویکرد سنتی، ترتیبی و برنامه محور مقایسه می‌کنیم. همانطور که در بخش‌های قبلی طبق اصول 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

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


تعریف آماده:
در هنگام فعالیت آماده سازی، اطمینان از آمادگی اقلام برای انتقال به اسپرینت و توسعه توسط تیم تا پایان اسپرینت موضوع مهمی است لذا کلمه «آماده» تعریفی است که تیم اسکرام استفاده می‌کند

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

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

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

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

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

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

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

#scrum

@code_crafters

برآورد و سرعت

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

چه تعداد ویژگی‌هایی باید انجام شود؟
انجام این ویژگی‌ها چه زمانی به پایان می‌رسد؟
هزینه انجام این ویژگی‌ها چقدر خواهد شد؟

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

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

اگر اندازه انتشار ۱، ۲۰۰ امتیاز باشد و سرعت تیم در هر اسپرینت ۲۰ امتیاز باشد، ۱۰ اسپرینت طول می‌کشد تا انتشار ۱ کامل شود

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

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

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

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

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

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

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

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

#scrum

@,code_crafters

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

۴-براورد نسبی اندازه‌ها
بجای اندازه‌های مطلق با اندازه‌های نسبی برآورد کنیم. جهت بررسی بزرگی هر قلم آن را نسبت به بقیه با هم مقایسه میکنیم

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

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

روز ایده‌آل:
تعداد روزهای کاری یا نفر-روز مورد نیاز جهت تکمیل داستان کاربر را نشان می‌دهد. زمان ایده‌آل با زمان سپری شده یکی نیست. یمی از جنبه‌های منفی زمان ایده‌آل، سوء برداشت از آن است

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

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

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

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

سرعت چیست؟
مقدار کار تکمیل شده در یک اسپرینت، که با جمع اندازه‌ی اقلام بک‌لاگ تکمیل شده تا پایان اسپرینت برابر است. وضعیت هر قلم یا انجام شده است یا انجام نشده، قلم نیمه کاره یا ناتمام ارزشی برای مالک ندارد لذا در سرعت به اقلام ناتمام توجهی نمی‌شود.
سرعت خروجی را اندازه گیری میکند نه نتیجه را. اندازه قلم ارزش آن نیست، بلکه ارزش از دید کسب و کار معین می‌شود (قلم با اندازه ۸ ارزش بیشتری از قلم با اندازه ۳ ندارد و ترکیب و اولویت با ارزش است نه اندازه)

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

محاسبه محدوده‌ی سرعت:
سرعت وقتی بصورت محدوده عددی باشد کاربرد بیشتری دارد، مثلا تیم تا ۲۰ امتیاز را در هر اسپرینت می‌تواند کامل کند. استفاده از عدد می‌تواند بدور از وسواس دقیق باشیم. از این طریق میتوان به سوالاتی از قبیل

چه زمانی کار تمام میشود؟
چه تعداد قلم را می‌توان تکنیل کرد؟
کل هزینه چقدر خواهد بود؟

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

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


#scrum

@code_crafters

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

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


#scrum

@code_crafters

بدهی فنی

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

مفاهیمی دیگر برای بدهی فنی:

طراحی نامناسب یا بد: طراحی که زمانی مورد مقبول و معقول بود اما به دلیل تغییرات مهم کسب و کار یا تکنولوژی، دیگر نیستند

نقص‌ها: مشکلات شناخته شده‌ای که تا کنون زمانی برای آن گذاشته نشده

پوشش ناکافی آزمون‌ها: بخش‌های مورد نیاز جهت آزمون بیشتر و بجا مانده

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

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

کم تجربگی در استفاده از سکو: استفاده از زبانی که برنامه‌نویس خبره در آن کم داریم

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

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

نوع دیگربدهی «بدهی فنی استراتژیک» است که ناشی از تصمیمات اقتصادی است و بیشتر ابزاری است(انتشار یک نسخه اولیه تا بعد از کسب درآمد سیستم را بهتر کرد)

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

پیامدهای بدهی فنی
با افزایش بدهی فنی، پیامدهای آن نیز افزایش می‌یابد:

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

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

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

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

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

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

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

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

@scrum

@code_crafters

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

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

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

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

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

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

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


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

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

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

#scrum

@code_crafters

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

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

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

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

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

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

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


#scrum

@code_crafters