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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


#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

رویکردهای بازپرداخت بدهی فنی

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

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

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

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

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

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

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

#scrum

@code_crafters

مالک محصول

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

مالک هم تحلیل‌گر کسب و کار است هم آزمون‌گر

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

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

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


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

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

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

#scrum

@code_crafters

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

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

خصوصیت‌ها و مهارت‌ها
خصوصیت‌های مالک را میتوان به چهار گروه تقسیم کرد:مهارت‌های دامنه مسئله،مهارت‌های انسانی،قدرت تصمیم گیری و پاسخ گویی

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

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

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

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

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

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

#scrum

@code_crafters

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

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

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

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

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

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


#scrum

@code_crafters

chat.deepseek.com

هوش مصنوعی چینی‌ها جهت رقابت با gpt و gemini

خوبیش اینه تحریم‌نیستیم

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

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


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

سوالات حول محور
Tdd
Ddd
Ci/cd
Rest
Storage
Microservice
Sso
Documentaion
Agile
Scrum
Searching
Protocol
Docker

و چالش‌های سازمانی بود

#free