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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


#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

تیم توسعه

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

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

مسئولیت‌های اصلی
تصویر اول در کامنت‌ها، فعالیت‌ها و مسئولیت‌های اصلی تیم توسعه را نشان می‌دهد

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

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

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

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

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

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

#scrum

@code_crafters

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

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

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

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

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

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

#scrum

@code_crafters

از جمله نکات مثبت تیم‌های کوچک

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

تیمی بسیار کوچک است که افراد کافی برای انجام کار نداشته باشد یا اعضا بقدری کم باشند که نتوانند به شکلی کارا و موثر کار کنند. این مسیله به معنای ناسازگاری اسکرام برای کارهای بزرگ نیست منتها بجای یک تیم ۳۶ نفره چهار تیم ۹ نفره خواهیم داشت.شاخص بزرگی پروژه‌های اسکرام،بزرگی تیم توسعه نیست بلکه تعداد تیم‌های اسکرام است.تیم‌ها میتوانند با رویکرد اسکرام اسکرام‌ها تعامل و جلسات روزانه برگذار کنند که اعضای تیم‌ها باهم جمع می‌شوند

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

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

۱۰- دیرپا
برای اثربخشی اسکرام تیم لازم است،نه گروه

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

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

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

#scrum

@code_crafters

خب تا اینجای کار که اومدیم

و طبق متن‌های بالا ما به تعریف از تیم پی بردیم و دید مهندسی نرم افزار مدرن الان میدونیم تیم به چه معناست


یکی از اصول میکروسرویس وجود تیم اجایل هستش و شما بدون اجایل درواقع میکروسرویس ندارین هرچقدر هم میکروسرویسی کد بزنید بازهم بدون تیم اجایل شما میکروسرویس ندارید و پروژه شکست خورده هستش

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

نبود دانش کافی و ناظر بر پروژه مطابق استانداردهای مختلف داخلی و بیرونی

نبود مدیران رده بالا در تعیین ابزارهای راهبردی و زیرساختی و از همه مهمتر تعیین سطح استاندارد ویژگی‌های پروژه

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

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


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

#free

@code_crafters

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

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

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

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


#free

@code_crafters

ساختارهای تیم اسکرام

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

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

#scrum

@code_crafters

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

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

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

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

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

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

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

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

را داشته باشد

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

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

#scrum

@code_crafters

مدیران

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

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

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

-تعیین اهداف شفاف
مدیران تعیین کننده اهداف تیم هستند که موجب می‌شود تیم انگیزه و جهت بگیرد. مالک مسئول تعریف دقیقتر آن است

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

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

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

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

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

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

#scrum

@code_crafters