۳-درک کردن جنبه‌های اقتصادی بدهی فنی به خوبی
جهت استفاده استراتژیک و سودمند بدهی فنی درک تاثیر آنها بر جنبه اقتصادی مهم است. برای مثال:
یک محصول برای انتشار مدنظر نیاز به ده ماه دارد و برای ارائه جنبه‌های مهمتر و بهتر بعلاوه سه ماه دیگر نیاز دارد. دو راه حل جهت بررسی وجود دارد. ابتدا با قسمت بازاریابی و فروش متوجه میشویم تاخیر در سه ماه n مقدار هزینه دارد (سود از دست رفته یا رسیدن به آن). با تیم فنی صحبت میکنیم و میگوییم اگر ساختار را تغییر دهید چه مقدار هزینه دارد و تیم فنی n-m را مطرح میکند. اینجا مشخص است که بررسی نشان میدهد روی گزینه دوم یعنی تیم توسعه فشار بیاوریم چون صرفه اقتصادی دارد اما این زمانی مورد مقبول است که مطمئن باشیم تمام حنبه‌های بدهی فنی از قبیل توسعه بغرنج، عدم پشتیبانی از ویژگی جدید و ... را بررسی کرده باشیم (نکته حائز اهمیت اکثر سازمانها بدهی فنی خود را بازپرداخت نمی‌کنند).
اگر یدهی فنی از لحاظ اقتصادی اجتماب ناپذیر باشد، محبور به پذیرش آن هستیم برای مثال از دست دادن رتبه اول بازار نسبت به رقبا یا در صورت عدم ارائه آن محبور به تعطیل شدن کسب و کار میشویم. تحریه نشان داده سازمانها به بدهی فنی نمیپردازند یا هزینه کافی نمی‌کنند پس تا حای ممکن از پذیرش آن اجتناب کنید
آشکارسازی بدهی فنی
یکی از مزایای استفاده از استعاره بدهی‌فنی کمک کردن به تیم فنی و کسب و کار جهت ارتباط گرفتن با ادبیات یکسان و مشترک است. برای گفتگو هر دو طرف باید وضعیت بدهی فنی محصول را به گونه‌ای که برایشان قابل فهم باشد ببینند
۱-آشکارسازی بدهی فنی در سطح کسب و کار
یکی از مشکلات موجود در سازمانها عدم درک و شناخت بدهی‌فنی در افراد حوزه کسب و کار است در حالیکه تیم فنی بدهی را دقیق میداند، این ضروریست که افراد کسب و کار نیز باید آن را بدانند تا از شرایط موجود اطلاع داشته و تصمیم‌های بهتر و مهمتر اقتصادی را بگیرد. یکی از موارد مشخص شدن آن پایش سرعت در طول زمان است بدهی فنی سرعت تیم را کاهش میدهد و این مورد را میتوان با هزینه مالی مشخص کرد برای مثال: تیم در هر اسپرینت ۲۰ امتیاز سرعت دارد و هزینه مالی آن ۲۰k است، اکنون بابت بدهی فنی امتیاز تیم در هر اسپرینت به ۱۰ رسیده است یعنی هزینه دو برابر شده است
۲-آشکارسازی بدهی فنی در سطح فنی
اکثر تیم فنی از بدهی اطلاع دارند اما اطلاعات تلویحی و غیرمستندی است و بگونه‌ای قابل تحلیل و ببرسی باشد نیست. سه روش آشکارسازی بدهی فنی در سطح فنی:
روش اول: به عنوان یک نقص در سیستم ردیابی نقص ثبت شود. مزیت آن ثبت در محلی آشنا و با استفاده از ابزارها و تکنیک‌های شناخته شده است. جمع اوری بدهی و نقص‌ها در یک مکان نیازمند نشانه گذاری جهت تفکیک است زیرا ممکن است روش رسیدگی به هرکدام متفاوت باشد
روش دوم: ایجاد اقلامی در بک‌لاگ محصول جهت نشان دادن بدهی فنی، بدین ترتیب هم تراز با ویژگی‌های جدید می‌شوند زمانی استفاده میشود که بدهی زیاد باشد و نیاز به حصگضور مالک جهت بررسی ارزش بدهی با ویژگی جدید جهت اولویت بندی است
روش سوم: ایجاد بک‌لاگ بدهی فنی که باعث آشمار شدن تک تک بدهی‌ها میشود، یک رویکرد ساده نصب تابلوی بدهی فنی روی دیوار است این تابلو در کنار تابلو بک‌لاگ اسپرینت قرار میگیرد تا تیم در برنامه ریزی خود جای دهد، آشکارسازی آن کمک میکند تا زمان دقیق بازپرداخت آن را بدانیم
تصویر اول در کامنت
بازپرداخت بدهی فنی
اخرین فعالیت در مدیریت بدهی فنی، بازپرداخت آن است. برای بازپرداخت آن بهتر است از طبقه بندی زیر استفاده کنیم
-بدهی فنی اتفاقی: نوعی بدهی است که در طی انجام کارهای عادی روی محصول ظاهر میشود و تیم توسعه تا آن زمان از وجود آن اطلاع نداشته (کد نوشته شده به شکل نادرست توسط فردی که تیم را ترک کرده است)
-بدهی فنی شناخته شده: بدهی که برای تیم فنی شناخته شده است و با یکی از رویکردهای قبلی آشکار شده است
-بدهی فنی هدف گذاری شده: بدهی شناخته شده که بازپرداخت آن در دستور کار تیم توسعه قرار گرفته است
اکنون رویکرد زیر را داریم:
۱- تعیین پرداخت بدهی فنی یا خیر، در صورت مثبت بودن مرحله بعد
۲- شروع به بازپرداخت بدهی کنید اگر بدهی جدیدی آشکار شد کد را پاکسازی و درجا پرداخت کنید و اگر تعدد بالا بود کد را پاکسازی و پرداخت‌ها را انجام دهید تا به حداقل بدهی باقی بماند. بدهی باقی مانده یا جدید را در بک‌لاگ یا بخش نگهداری بدهی‌ها بگذارید
۳- در هر اسپرینت بخشی از بدهی فنی شناخته شده را به عنوان بدهی فنی هدف گذاری شده تعیین کنید تا در طول اسپرینت بازپرداخت شود اولویت با بدهی‌هایی است که نرخ بهره بالا و در جهت کارهای با ارزش برای مشتری است
#scrum
@code_crafters
👍4
رویکردهای بازپرداخت بدهی فنی
قبلا صحبت کردیم که بک‌لاگ بدهی فنی چیست، در این رویکرد هنگام انتخاب اقلام توسط تیم و همراه مالک این تابلو کنار تابلو اقلام قرار میگیرد و هنگام انتخاب هر قلم با توجه به تابلوی بدهی اگر قلمی در تابلوی بدهی وجود داشته باشد که مرتبط با قلم انتخاب شده بک‌لاگ محصول باشد برویده و در کنار آن جهت رسیدگی گذاشته میشود و این یک رویکرد ساده جهت همسو سازی است. تصویر اول در کامنت
#scrum
@code_crafters
۱-نیازی به بازپرداخت همه بدهی‌های فنی نیست
همه بدهی‌های فنی نیازی به بازپرداخت ندارند و حتی ممکن به تعویق بیافتند در اینجا سه درباره سه مورد آن بحث میکنیم: اواخر عمر محصول، نمونه اولیه دور ریختنی و محصول ساخته شده برای کوتاه مدت
۲- اجرای قانون پیشاهنگی(بازپرداخت بدهی هنگام کشف اتفاقی آن)
در هنگام توسعه ویژگی جدید ممکن است یک بدهی کشف شود که سریع آن را پرداخت خواهیم کرد و دنبال دلیل و یا نفر آن نمیگردیم این سیستم کمک میکند بدهی کمتری داشته باشد، کا انتظار نداریم که سیستم بدهی نداشته باشد اما پایین نگه داشتن آن بسیار الزامی است، انتظار از نداشتن بدهی یا بازپرداخت کامل آن منحر میشود به هدف اسپرینت نرسیم. در اسکرام تیم توسعه دو رویکرد برای آن دارد، رویکرد اول این است برای امتیازدهی به هر یک از اقلام اندکی امتیاز بیشتر می‌دهیم که برای بازپرداخت بدهی فنی استفاده میشود، رویکرد دوم این است بین ۵تا۳۳ درصد از هر اسپرینت را به بازورداخت بدهی صرف کنیم. بدهی اتفاقی بازپرداخت نشده باید سریعا بعنوان بدهی شناخته شده ثبت شود
۳-بازورداخت تدریجی بدهی فنی
بازپرداخت بدهی فنی بهتر است مطابق برنامه و اندک اندک در هر اسپرینت صورت گیرد، بازپرداخت کامل بدهی مانند بازپرداخت یکجای یک وام است. «اسپرینت‌های بدهی فنی» یا «اسپرینت‌های بازسازی» واژه‌های وحشتناکی است که تیم بجای توسعه ویژگی جدید محصول وادار میشود که بازپرداخت انجام دهد. ما این را می‌پذیریم اما تا جای ممکن از آن پرهیز کنید و بدهی را تدریجی در هر اسپرینت پرداخت نمایید، برنامه ریزی پرداخت بدهی توسط تیم اسکرام در طی برنامه ریزی اسپرینت صورت میگیرد که بخشی از بدهی شناخته شده را با عنوان بدهی فنی هدف کذاری شده برای بازپرداخت در اسپرینت بعدی انتخاب میکنیم
۴-ابتدا بدهی با بهره بالا را بازپرداخت کنید
بدهی‌های فنی ارزش یکسانی ندارند برخی بدهی‌ها مانند یک ماژول که در جاهای مختلفی استفاده شده ارزش بیشتری دارد لذا باید ابتدا این بدهی‌ها بازپرداخت شود مگر اینکه یک دلیل قانع کننده وجود داشته باشد برای مثال برخی سازمانها بدهی زیادی تولید میکنند و نمیدانند چگونه به آن رسیدگی کنند لذا جهت روی غلطک افتادن ابتدا از بدهی‌های کوچک شروع میکنند ما با هرچیزی که موجب افزایش دانش فنی شود موافق هستیم، فراموش نکنید در هر اسپرینت بخشی از بدهی را بازپرداخت نمایید
۵-بدهی فنی را همزمان با انجام کار با ارزش برای مشتری بازپرداخت کنید
یکی از از روش‌های بسیار عالی بازپرداخت بدهی هنگام توسعه اقلام بارارزش و ویژگی جدید برای مشتری است که موجب میشود بدهی با ارزش بالاتر پرداخت شود و همسو با ارزش محورست اسکرام میز پیش برو، این رویکرد موجب میشود تا از اختصاص یک اسپرینت برای بدهی جلوگیری شود. در این رویکرد ابتدا ما متعهد میشویم که بدهی ناشی از بی‌تجربگی اضافه نکنیم، ثانیا قانون پیشاهنگی را نیز انجام دهیم (کشف اتفاقی بدهی و پاکسازی کد و پرداخت آن) و ثالثا بدهی فنی هدف کذاری شده را از بخش‌هایی انتخاب میکنیم که در آینده روی آن کار میکنیم
مزیت‌های این رویکرد:
- همسو سازی کاهش بدهی و کار با ارزش برای مشتری، که موجب میشود مالک بهتر اولویت بندی کند
-گوشزد کردن به تیم که بدهی برای همه است و نه فرد یا تیم خاصی پس در بازپرداخت آن همه سهیم هستند
-موحب تقویت و افزایش مهارت‌های کاهش و حلوگیری از بدهی فنی میشود
-کمک به شناسایی بخش‌ها با بهره بالا که موجب میشود ما درک کنیم بخش توسعه داده شده همچنان در آینده ما با آن سروکار داریم
-جلوگیری از عدم بازپرداخت بدهی‌هایی که اجباری برای آن وجود ندارد
قبلا صحبت کردیم که بک‌لاگ بدهی فنی چیست، در این رویکرد هنگام انتخاب اقلام توسط تیم و همراه مالک این تابلو کنار تابلو اقلام قرار میگیرد و هنگام انتخاب هر قلم با توجه به تابلوی بدهی اگر قلمی در تابلوی بدهی وجود داشته باشد که مرتبط با قلم انتخاب شده بک‌لاگ محصول باشد برویده و در کنار آن جهت رسیدگی گذاشته میشود و این یک رویکرد ساده جهت همسو سازی است. تصویر اول در کامنت
#scrum
@code_crafters
❤6
مالک محصول
مرور
مالک کانون اصلی و قدرتمند محصول است که یکی از سه نقش اسکرام را برعهده دارد (استاد، تیم، مالک) مالک باید همزمان به دو سویه توجه داشته باشد از یک سو نیازها و اولویت‌های ذینفعان سازمانی، مشتریان و کاربران را به خوبی درک کند و صدای آنان باشد(بعنوانی مانند یک مدیر محصول عمل کرده و مطمئن شود راهکار درستی در حال توسعه است) و از سوی دیگر باید درباره محصول در حال ساخت و ترتیب ساخت آن با تیم توسعه در تعامل باشد (اطمینان از معیارهای پذیرش ویژگی‌های مشخص شده و آزمون‌هایی که این معیارها را تاید و صحه‌گذاری کند اجرا شده باشند) مالک آزمونهای جزئی نمی‌نویسد بلکه مطمئن میشود آزمونهای کلان بگونه‌ای نوشته شده باشد که تیم از روی آن بفهمد که ویژگی چه زمانی از نظر مالک تکمیل تلقی میشود
مالک هم تحلیلگر کسب و کار است هم آزمونگر
مسئولیت‌های اصلی
مالک دارای مسئولیت‌های بسیاری است که گاه به این فکر میکنیم که آیا یکنفر میتواند از عهده تمام آن بر بیاید یا همه خصوصیات لازم را داشته باشد. مالک محصول هر تیم تنها یکنفر است هرچند در شرایط خاص استفاده از تیم مالک یا نماینده مالک عملی‌تر است
#scrum
@code_crafters
مرور
مالک کانون اصلی و قدرتمند محصول است که یکی از سه نقش اسکرام را برعهده دارد (استاد، تیم، مالک) مالک باید همزمان به دو سویه توجه داشته باشد از یک سو نیازها و اولویت‌های ذینفعان سازمانی، مشتریان و کاربران را به خوبی درک کند و صدای آنان باشد(بعنوانی مانند یک مدیر محصول عمل کرده و مطمئن شود راهکار درستی در حال توسعه است) و از سوی دیگر باید درباره محصول در حال ساخت و ترتیب ساخت آن با تیم توسعه در تعامل باشد (اطمینان از معیارهای پذیرش ویژگی‌های مشخص شده و آزمون‌هایی که این معیارها را تاید و صحه‌گذاری کند اجرا شده باشند) مالک آزمونهای جزئی نمی‌نویسد بلکه مطمئن میشود آزمونهای کلان بگونه‌ای نوشته شده باشد که تیم از روی آن بفهمد که ویژگی چه زمانی از نظر مالک تکمیل تلقی میشود
مالک هم تحلیلگر کسب و کار است هم آزمونگر
مسئولیت‌های اصلی
مالک دارای مسئولیت‌های بسیاری است که گاه به این فکر میکنیم که آیا یکنفر میتواند از عهده تمام آن بر بیاید یا همه خصوصیات لازم را داشته باشد. مالک محصول هر تیم تنها یکنفر است هرچند در شرایط خاص استفاده از تیم مالک یا نماینده مالک عملی‌تر است
۱- مدیریت امور اقتصادی
مسئولیت از کسب اطمینان از درستی تصمیم اقتصادی که در اسپرینت و بک‌لاگ گرفته می‌شوند:
-امور اقتصادی در سطح انتشار: مالک با ورود اطلاعات مهم اقتصادی در طی توسعه به تیم، ما بین محدوده، تاریخ انتشار، بودجه و کیفیت تولزن برفگقرار میکند. مالک میتواند با توجه به دیدگاه اقتصادی توسعه محصول را برای اسپرینت بعدی متوقف کند. برای مثال عدم‌توجیه پذیر بودن هزینه اسپرینت بعدی، کافی بودن ویژگی‌های تا کنون محصول نسبت به بازار و نداشتن توجیه اقتصادی مابقی اقلام در بک‌لاگ(اقلام مهم در بالای بک‌لاگ قرار دارند)، تغییر وضعیت بازار به هر دلیلی مانند ثبت قانون حدید یا تغییر کلی وضعیت بازار و ...
-امور اقتصادی در سطح اسپرینت: مالک در سطح اسپرینت برای بازگشت سرمایه تصمیماتی میگیرد. مالک از میزان هزینه اسپرینت بعدی آگاه است (زمان و تعداد نفرات) و خود میپرسد آیا بصرفه است اینکار را انجام دهم
-امور اقتصادی در سطح بک‌لاگ:
مالک مسئول اولویت بندی اقلام در بک‌لاگ است و ممکن با توجه به شرایط اقتصادی اولویت بندی را تغییر یا اقلامی را حذف کند
۲- مشارکت در برنامه ریزی
مالک یکی از اعضای مهم در برنامه ریزی‌های سبد محصول،برنامه‌ریزی محصول،برنامه‌ریزی انتشار و برنامه‌ریزی اسپرینت است
در برنامه‌ریزی سبد محصول مالک با همکاری ذینفعان داخلی که کمیته تصمیم گیری یا نظارت هستند، جایگاه محصول در بک‌لاگ محصول و زمان شروع و پایان را تعیین میکند. در برنامه‌ریزی محصول چشم‌انداز محصول را با همکاری ذینفعان ترسیم میکند. در برنامه‌ریزی انتشار محتوای انتشار بعدی را با ذینفعان و تیم تعریف میکند. در برنامه ریزی اسپرینت هدف اسپرینت را تیم مشخص میکند. همچنین کمک میکند که تیم اقلام با ارزشی را بردارد که واقعا از عهده آن بر می‌آید
۳- آماده سازی بک‌لاگ محصول
مالک مسیولیت بک‌لاگ محصول را برعهده دارد که شامل فعالیت‌های ایجاد،اصلاح،برآورد و اولویت بندی اقلام است. مالک همه اینکارها را خود به تنهایی انجام نمی‌دهد در ممکن است همه اقلام را خود ننویسد یا در برآورد تیم اینکار انجام میدهد و مالک جهت شفاف سازی و پاسخ دهی حضور دارد. به هرحال مالک مسئول فعالیت‌های آماده سازی به شکلی که موجب افزایش سرعت جریان ارزش آفرینی است
۴- تعریف معیار پذیرش و تایید تحقق آن
مالک مسئول تعریف معیارهای پذیرش برای تک تک اقلام است تا در صورت تحقق مالک متقاعد شود. در این مسیر مالک از خبرگان موضوع یا تیم توسعه کمک میگیرد. مالک قبل از طرح قلم در جلسه برنامه ریزی اسپرینت باید مطمین باشد که معیارهای پذیرش و اکثر آزمونهای پذیرش مشخص و ثبت شده باشند. بدن این موارد قلم کامل و آماده ورود به اسپرینت نیست. وجود معیارهای شفاف به عنوان یکی از ردیف‌های چک لیست «تعریف آماده» است. مالک شخصا آزمونهای پذیرش را اجرا میکند یا از کاربران باتجربه کمک میگیرد تا تحقق شرط‌های رضایت‌مندی اقلام بک‌لاگ محصول را تایید کند. تیم زیرساختی را جهت اجرای آزمون‌ها در اختیار مالک یا خبرگان می‌گذارد. ازمون‌ها نباید به زمان بازنگری اسپرینت موکول گردد تا مالک با اجرای آن اشتباهات و برداشت‌های غلط را مشخص و در بازنگری اسپرینت مطرح کند. بدینگونه تیم تشخیص میدهد کدام یک از ویژگی‌ها واقعا با «تعریف انجام شده» مطابقت دارد
۵- همکاری با تیم توسعه
مالک باید حضوری تمام وقت و منظم با تیم داشته باشد. عدم ارتباط گیری با تیم موجب بازخوردهای منفی میشود و بازخوردهای مفید دیرتر به تیم می‌رسد. در توسعه سنتی الگوی مشارکت به شکل U است ابتدا سریع و کامل می‌ایند و در در میانه حضور ندارند تا پایان توسعه نیز باز نمیگردند
#scrum
@code_crafters
👍3
این موحب میشود محصولی ساخته شود که مطابق نیاز مشتریان نیست و اتهام زنی‌ها شروع می‌گردد. در اسکرام ما در هر مرحله در حال انجام یک کار نیستیم بلکه در حال توسعه ویژگی‌ها هستیم این بدین معناست تمامی فعالیت‌های ساخت یک ویژگی یعنی طراحی، کدنویسی، یکپارچه‌سازی و آزمون را در طول اسپرینت انحام می‌دهیم. به همین دلیل مشارکت بسیار زیاد و بی‌وقفه مالک ضروری است
۶- همکاری با ذینفعان
مالک باید صدای ذینفعان داخلی(صاحبان سیستم‌های کسب و کار، مدیریت اجرایی، مدیریت برنامه، بازاریابی و فروش ) و خارجی(مشتریان، کاربران، شرکتهای همکار، نهاذهای قانون گذار و ...) باشد. عدم رسیدگی کالک به وظایف از بابت مشغلگی زیاد، زیان اور است لذا مالک میتواند از دیگران برای انجام کارهایش کمک بگیرد
خصوصیت‌ها و مهارت‌ها
خصوصیت‌های مالک را میتوان به چهار گروه تقسیم کرد:مهارت‌های دامنه مسئله،مهارت‌های انسانی،قدرت تصمیم گیری و پاسخ گویی
مهارت‌های دامنه مسئله:
فردیست دوراندیش که قادر است چشم‌اندازی برای محصول تدوین کند و تیم را در جهت دستیابی به این چشم انداز هدایت نماید(این به معنای شفافیت کامل همه چیز نیست)،هر مالکی میداند که در ابتدا همه چیز مشخص و واضح نیست خود را آماده تغییر مناسب و ضروری میکند. مالک به منظور افزایش اثربخشی در تدوین و اجرای چشم انداز، باید دانش مناسب و قابل قبولی درباره کسب و کار و دامنه مسئله داشته باشد.فرد تازه کار در دامنه محصول به سختی مالک موفقی میشود. اگر موضوعی را ندانید چگونه میتوانید ویژگی‌های مربوط به آن را اولویت بندی کنید؟
مهارت‌های انسانی:
مالک باید صدای مشتری باشد که لازمه آن داشتن رابطه خوب با ذینفعان است. ذینفعان متعدد موجب نیازهای متناقض هستند لذا مالک باید مذاکره کننده ماهری باشد که بین ذینفعان اتفاق نظر و اجماع ایجاد کند و از سمت دیگر اتصال ذینفعان با تیم توسعه است به همین دلیل نیاز به مهارت ارتباطی قوی دارد تا اطلاعات را با زبانی مناسب بین دو گروه منتقل کند. فردی با مهارت ارتباطی قوی از خصلت‌های دیگر نیز برخوردار است از جمله: آماده است تا عقاید خود را حتی اگر با وضعیت موجود ناسازگار باشد با صدای بلند بیان کند، نسبت به ایده‌هایش اطمینان دارد، به موضوع مسلط است،میتواند اطلاعات را ساده، مختصر و قابل فهم بیان کند و قابل اعتماد است.و همچنین فردی توانا برای ایجاد انگیزه در افراد است.زمانیکه کارها خوب پیش نمی‌رود به افراد یاداوری میکند به چه علت کار میکنند و با تشریح مجدد آینده کسب و کار به آنها در داشتن نگاهی پرشور و حفظ آن کمک میکند
قدرت تصمیم گیری:
مالک باید قدرت تصمیم گیری داشته باشد در سازمانهای نوظهور چنین قدرتی به مالک نمی‌دهند. چنین فردی مالک نیست. مالک باید اماده تصمیم‌گیری‌های دشوار باشد که معمولا با سبک و سنگین کردن قیدهایی همچو زمان و بودجه همراه است.تصمیم‌هاباید بموقع گرفته و بدون دلیل لغو نگردند (تصمیم گیری قاطع و مصمم) در چنین تصمیم‌گیری‌هایی مالک باید بین نیازهای کسب و کار و واقعیت‌های فنی توازن برقرار کند. وقتی که سیستم در وضعیت غیرقابل قبول بدهی فنی قرار دارد کل تیم اسکرام مسئول است اما تصمیم‌های بدون دقت مالک محصول عامل تاثیرگذار و مهمی در ایجاد بدهی بشمار می‌رود بالاخص تصمیم‌هایی که قصور او و بدون توجه به اثرات آن در سیستم ایجاد شده است
پاسخ‌گویی:
مالک مسئول و پاسخگوی اصلی نتایج مطلوب برای کسب و کار است.اما این موجب نمیشود تا سایر اعضای اسکرام از بازگشت سرمایه معاف باشند.با این حال مالک مسئول کسب اطمینان از استفاده اقتصادی از منابع است و در غیر اینصورت باید پاسخگو باشد. مالک فرصت‌های زیادی برای تغییر بک‌لاگ، اولویت بندی یا حتی توقف توسعه را در اختیار دارد. مالک محصول فردی متعهد و در دسترس ذینفعان و اعضای تیم است. شغلی تمام وقت و انجام پاره وقت آن منحر به شکست میشود. مالک به گروه اسکرام معتقد است و با آنها با احترام برخورد کرده و میداند همه در دستیابی نتایج مطلوب شریک و تلاش میکنند
چه کسی باید مالک محصول باشد
مالک محصول باید همزمان دو سویه را در نظر بگیرد (ذینفعان و تیم فنی) لذت ترکیبی از اختیارات و مسئولیت‌های مختلف است که در چندین نقش وجود دارد:مدیر محصول، مدیر بازاریابی محصول، مدیر پروژه، مدیر تحلیلگر کسب و کار و آزمونگر پذیرش
اینکه چه کسی مالک باشد بستگی به نوع توسعه و سازمان دارد
۱-توسعه داخلی: یکنفر از اعضا که از توسعه سود میبرند و دارای قدرت و اختیارات است (توسعه سیستم برای بخش بازاریابی، یکنفر از بازاریاب‌ها)
۲-توسعه تجاری: یکی از کارمندان که بتواند صدای مشتریان باشد این فرد از بین مدیران محصول یا مدیران بازاریابی محصول انتخاب میشود
۳-پروژه برون سپاری: یکنفر نماینده از طرف شرکت درخواست کننده پروژه، یکنفر نماینده از شرکت انجام دهنده جهت ارتباط
#scrum
@code_crafters
👍3
اگر قرارداد بصورت مبلغ ثابت باشد کار مالک سخت و پیچیده میشود و شرکت انجام دهنده میداند که خود باید بیشتر مسئولیت‌های مالک را گردن بگیرد چونکه ریسک قرارداد را گردن گرفته، بهتر است قرارداد جوری باشد که شرکت درخواست کننده تیم و استاد را به از شرکت امجام دهنده به خدمت بگیرد و مالک محصول را از داخل انتخاب کند
۴-توسعه مولفه
برخی سازمانها از تیم‌های مولفه محور استفاده میکنند که آنها تنها بخشی از از راهکار مشتری را می‌سازند نه تمام آن را، هدف این تیم‌ها ساخت دارایی‌هایی است که برای همه تیم‌های دیگر با ارزش است در این تیم‌ها یکنفر با نگرش فنی نقش مالک را برعهده میگیرد که توانایی نوشتن اقلام و اولویت بندی بک‌لاگ را داشته باشد. برخلاف آن مالک تیم‌های ویژگی محور تخصص فنی کمتری دارد یا ندارد. تصویر اول در کامنت
ترکیب نقش مالک محصول با سایر نقش‌ها
طبیعی است که یکنفر مالک محصول چند تیم باشد اگر میزان فشار کاری کم باشد و اهداف تیم‌ها یکسان باشد، همچنینی مالک محصول میتواند عضوی از تیم فنی نیز باشد اما نمی‌تواند استاد هم باشد چونکه این دو نقش برای تعادل ایجاد شده و در صورت یکی شدن تضاد منافع صورت میگیرد
تیم مالک محصول
اساسا تشکیل تیم مالک محصول منتفی است مگر اینکه مالک مشغله داشته باشد و برخی از افراد را مسئول برخی وظایف خود کند. مالک محصول باید تنها یکنفر با قدرت و اختیار باشد و گروه قابل قبول نیست که جمعی تصمیم گیری کنند (اگر مالک ضعیفی دارید با ایجاد تیم درست نمیشود بلکه باید شغلش را تغییر دهید)، اگر چندین تیم دارید پس چندین مالک هم دارید، اگر چندین تیم با یک مالک دارید شاید مشکل از سازمان باشد که چند پروژه رو باهم شروع کرده است، اگر پروژه بزرگ باشد و به چندین بخش شکسته شده باشد باز هم یکنفر میتواند مالک همه آنها باشد و اگر تیم‌ها ضعیف چیده شده باشند یا بک‌لاگ درست تهیه نشده باشد ابتدا مطمئن شوید که هدف از تشکیل تیم مالک پنهان کردن یا سرپوش گذاری بر موضوع دیگری نیست چونکه تیم مالک در شرایط نا به سامان فقط منحر به از بین رفتن دستاوردها و پیچیده شدن بیشتر شرایط میشود
نماینده مالک محصول
زمانیکه افراد کسب و کار مشغله زیاد دارند، سازمانها علاقه دارند نفری فنی را مالک کنند که اختیار تصمیم گیری ندارد (یکی از ارکان مهم برای مالک بودن) لذا بهتر است او نماینده مالک شود و به مالک و تیم کمک کند، مالک نباید تصمیمات نماینده خود را بی دلیل رد کند که موجب صلب اعتماد نماینده خود شود همچنین مالک نمی‌تواند نتیجه نهایی درستی انجام کار به کسی حتی نماینده خود واگذار کند
مالک محصول ارشد
اگر یک محصول انقدری بزرگ باشد که با شکستن آن به چندین بخش (هر تیم نهایتا شامل مجموعه‌ای ده نفره است) تعداد زیادی از بخش‌ها را ایجاد کند که از عهده یک مالک مشترک بر نیاید در این مواقع مالک محصول تیم مالکان محصول را ایجاد کرده و این اطمینان را حاصل میکند وظایف و دسترسی و ... کامل شکل گرفته باشد که برای هرکاری لازم به ارجاع به بالاتر نباشد تصویر دوم در کامنت
#scrum
@code_crafters
👍3
تیم توسعه
مرور
در رویکردهای سنتی توسعه نرم‌افزار شغل‌های مختلفی مانند: معمار، برنامه‌نویس، آزمونگر،راهبر پایگاه داده، طراح رابط کاربری و موارد مشابه آن وجود دارد. اما در اسکرام یک نقش با عنوان تیم توسعه تعریف میشود که مجموعه‌ای چندتخصصی از این افراد است که یکی از سه نقش اصلی اسکرام است. ممکن است به آن تیم، تیم تحویل یا عناوین دیگری نیز اطلاق شود اما تیم توسعه توافق اکثریت است
تیم‌های نقش محور
در بسیاری از سازمانها نقش‌های کاری را به‌شکل تیم‌های تخصصی و چندمحور سازماندهی میکنند. این سازمانها تیمی از طراحان، تیمی از توسعه دهندگان و تیمی از آزمونگرها دارند. وقتی کار یک تیم تمام میشود آن را به تیم دیگر تحویل میدهد. تیم‌ها کم و بیش مستقل از یکدیگر کار میکنند.
در اسکرام، تیم توسعه در هر اسپرینت باید کارهای لازم برای تولید یک یا چند بخش از محصول را انجام دهد. این کارها شامل طراحی، توسعه، یکپارچه‌سازی و آزمون است. از این رو به تیمی نیاز داریم که مهارت‌های لازم برای انجام همه‌ی این کارها را داشته باشد.
در برخی سازمانها هنگام استفاده از اسکرام تیم آزمونگر جدا دارند. ممکن است یکی از الزامات قانونی این باشد و وجود تیم آزمونگر جدا مناسب باشد. اما در اسکرام آزمون باید در اسپرینت صورت گیرد. اسکرام با تیم‌های نقش محور ناسازگاری دارد
مسئولیت‌های اصلی
تصویر اول در کامنت‌ها، فعالیت‌ها و مسئولیت‌های اصلی تیم توسعه را نشان میدهد
خصوصیات و مهارت‌ها
تیم توسعه باید دارای خصوصیات و مهارت‌های زیر باشد
۱- خودسازمانده
اعضای تیم خود را بگونه‌ای سازماندهی میکنند تا بهترین روش دستیابی به هدف اسپرینت انتخاب شود. مدیر پروژه یا مدیر دیگری وجود ندارد که روش انجام کار تعیین کند و استاد نیز نباید تصور کند اینکار برعهده اوست. خودسازماندهی یکی از خصوصیات تکاملی و پایین به بالای سیستم است هیچ قدرت کنترل کننده بیرونی وجود ندارد که تیم را با استفاده از مدیریت سمتی بالا به پایین و فرماندهی کند. خودسازماندهی ویژگی پایین به بالای سیستم‌های تطبیق پذیر پیچیده است. در چنین سیستم‌هایی، تعداد زیادی از موجودیت‌ها با شیوه‌های گوناگونی با یکدیگر در تعامل هستند و این تعاملات تحت کنترل قواعدی ساده و محلی قرار دارند و در فضایی با بازخوردهای بی‌وقفه و مداوم انجام می‌شوند اینگونه سیستم‌ها پایداری قابل توجه و نوآوری شگفت‌انگیزی دارند. مدیران تنها محیط را برای تیم خودسازمانده فراهم یا بازسازی میکنند
#scrum
@code_crafters
مرور
در رویکردهای سنتی توسعه نرم‌افزار شغل‌های مختلفی مانند: معمار، برنامه‌نویس، آزمونگر،راهبر پایگاه داده، طراح رابط کاربری و موارد مشابه آن وجود دارد. اما در اسکرام یک نقش با عنوان تیم توسعه تعریف میشود که مجموعه‌ای چندتخصصی از این افراد است که یکی از سه نقش اصلی اسکرام است. ممکن است به آن تیم، تیم تحویل یا عناوین دیگری نیز اطلاق شود اما تیم توسعه توافق اکثریت است
تیم‌های نقش محور
در بسیاری از سازمانها نقش‌های کاری را به‌شکل تیم‌های تخصصی و چندمحور سازماندهی میکنند. این سازمانها تیمی از طراحان، تیمی از توسعه دهندگان و تیمی از آزمونگرها دارند. وقتی کار یک تیم تمام میشود آن را به تیم دیگر تحویل میدهد. تیم‌ها کم و بیش مستقل از یکدیگر کار میکنند.
در اسکرام، تیم توسعه در هر اسپرینت باید کارهای لازم برای تولید یک یا چند بخش از محصول را انجام دهد. این کارها شامل طراحی، توسعه، یکپارچه‌سازی و آزمون است. از این رو به تیمی نیاز داریم که مهارت‌های لازم برای انجام همه‌ی این کارها را داشته باشد.
در برخی سازمانها هنگام استفاده از اسکرام تیم آزمونگر جدا دارند. ممکن است یکی از الزامات قانونی این باشد و وجود تیم آزمونگر جدا مناسب باشد. اما در اسکرام آزمون باید در اسپرینت صورت گیرد. اسکرام با تیم‌های نقش محور ناسازگاری دارد
مسئولیت‌های اصلی
تصویر اول در کامنت‌ها، فعالیت‌ها و مسئولیت‌های اصلی تیم توسعه را نشان میدهد
۱-اجرای اسپرینت
اعضای تیم در طول اسپرینت با انجام خلاقانه طراحی، ساخت، یکپارچه سازی و آزمون اقلام بک‌لاگ محصول، بخش قابل عرضه‌ای از محصول را آماده میکنند و بصورت خودسازمانده و گروهی برنامه ریزی، مدیریت، انجام و اطلاع رسانی کارها تصمیم میگیری میکنند. تیم توسعه بیشتر وقت خود را صرف «اجرای اسپرینت» میکند
۲-بازرسی و تطبیق روزانه
همه اعضای تیم توسعه موظفند در اسکرام‌های روزانه شرکت کنند، و به شکل گروهی میزان پیشرفت کار را نسبت به هدف اسپرینت بررسی کنند و برنامه روز حاری را مطالق آن تغییر دهند. شرکت نکردن برخی از اعضای تیم در اسکرام مانع این دستیابی به هدف اسپرینت میشود
۳-آماده سازی بک‌لاگ محصول
بخشی از هر اسپرینت باید صرف ایجاد آمادگی برای اسپرینت بعدی شود. تمرکز بخش عمده‌ای از این کار بر آماده سازی بک‌لاگ محصول است که شامل فعالیت‌های ایجاد، اصلاح، برآورد و اولویت‌بندی اقلام بک‌لاگ محصول است حدود ده درصد از هر اسپرینت را تیم صرف کمک به مالک جهت آماده سازی بک‌لاگ محصول میکند
۴- برنامه ریزی اسپرینت
در ایتدای هر اسپرینت تیم توسعه در برنامه ریزی اسپرینت شرکت میکند و با همکاری مالک و با راهنمایی استاد هدف اسپرینت جاری مشخص میشود. و تیم تعیین میکند که هدف اسپرینت با ساخت کدام یک از اقلام با اولویت یک‌لاگ محصول محقق میشود برنامه ریزی هر اسپرینت دو هفته‌ای حدود نصف روز طول می‌کشد و چهارهفته‌ای یک روز کامل طول می‌کشد. تیم بجای ارائه یک برنامه کلی که غیرقطعی و بیش از حدتفصیلی در ابتدای توسعه، مجموعه‌ای از برنامه‌های کوچکتر، قطعی‌تر و تفصیلی‌تر در ابتدای هر اسپرینت تهیه میکند
۵- بازرسی و تطبیق محصول و فرآیند
در پایان هر اسپرینت تیم در دو فعالیت بازرسی و تطبیق شرکت میکند: بازنگری اسپرینت و بازاندیشی اسپرینت. در بازنگری اسپرینت تیم،مالک،استاد،ذینفعان،حامیان، مشتریان و علاقمندان سایر تیم‌ها ویژگی‌هایی را که در اسپرینت جاری تکمیل شده است بازنگری کرده و در مورد بهترین روش ادامه کار با یکدیگر بحث و گفتگو میکنند. در بازاندیشی تیم فرایند اسکرام و تحربه‌های فنی خود را مورد بازرسی و تطبیق قرار میدهد تا با بهبود روش استفاده از اسکرام، ارزش‌های بیشتری برای کسب‌وکار خلق نماید
خصوصیات و مهارت‌ها
تیم توسعه باید دارای خصوصیات و مهارت‌های زیر باشد
۱- خودسازمانده
اعضای تیم خود را بگونه‌ای سازماندهی میکنند تا بهترین روش دستیابی به هدف اسپرینت انتخاب شود. مدیر پروژه یا مدیر دیگری وجود ندارد که روش انجام کار تعیین کند و استاد نیز نباید تصور کند اینکار برعهده اوست. خودسازماندهی یکی از خصوصیات تکاملی و پایین به بالای سیستم است هیچ قدرت کنترل کننده بیرونی وجود ندارد که تیم را با استفاده از مدیریت سمتی بالا به پایین و فرماندهی کند. خودسازماندهی ویژگی پایین به بالای سیستم‌های تطبیق پذیر پیچیده است. در چنین سیستم‌هایی، تعداد زیادی از موجودیت‌ها با شیوه‌های گوناگونی با یکدیگر در تعامل هستند و این تعاملات تحت کنترل قواعدی ساده و محلی قرار دارند و در فضایی با بازخوردهای بی‌وقفه و مداوم انجام می‌شوند اینگونه سیستم‌ها پایداری قابل توجه و نوآوری شگفت‌انگیزی دارند. مدیران تنها محیط را برای تیم خودسازمانده فراهم یا بازسازی میکنند
#scrum
@code_crafters
👍4
۲- دارای تخصص‌های گوناگون و کافی
اعضای تیم توسعه باید تخصص‌های مختلفی داشته باشند، آنها در مجموع باید مهارت‌های لازم و کافی را داشته باشند. تیمی که بخوبی شکل گرفته باشد میتواند قلمی را از بک‌لاگ محصول بردارد و ویژگی با کیفیتی تولید کند که با تعریف انجام شده اسکرام مطابقت داشته باشد. تیم‌هایی که مهارت‌های مشابه دارند به روش سنتی در نهایت مجبورند که محصولات را دست به دست کنند که احتمال ایجاد اشتباهات پرهزینه و سوتفاهم دارد. وجود تیم‌هایی که که افراد آن دارای تخصص‌های مختلف هستند، تعداد ارجاع کارها را کمینه میکند. تنوع و چند تخصصی بودن تیم‌ها، مزایای متعددی دارد و منحر به نتایج بهتری میشود. اعضای هر تیم چند تخصصی، پیش زمینه و معلومات مختلفی دارند. هر عضو مجموعه‌ای از ابزارهای شناختی خود را برای حل مسئله همراه می‌آورد که میتواند شامل تفسیرهای مختلف از داده‌های یکسان، ابتکارها، راهبردهای حل مسئله مدل‌های ذهنی درباره عملکرد اشیا و سلیقه‌های مختلف در انتخاب رویکرد یا راهبردهای حل مسئله، مدل‌های ذهنی درباره عملکرد اشیا و سلیقه‌های مختلف در انتخاب رویکردها و راهکارها باشد که منجر به افزایش ارزش اقتصادی میشود تصویر اول در کامنت
سعی کنید ترکیب درستی از افراد با تجربه و تازه‌کار ایجاد کنید. وجود افراد با تجربه در کنار هم ممکن است موجب شلوغی غیرضروری و بی‌مورد گردد
مهارت‌های تی شکل T
تیم‌های توسعه انعطاف پذیر از اعضایی با مهارت‌های تی شکل تشکیل شده است. هر یک از اعضای تیم در تخصص اصلی خود عمیق و در برخی تخصص‌های دیگر گستردگی دارد. این افراد میتوانند در زمان‌های گلوگاه سازمان عملکرد جمعی بهتری از خود نشان داده و به تیم برای رفع مشکل پیش آمده کمک کنند. اینکه هر عضو تیم قادر به انجام هرکاری باشد، تصور واقع بینانه‌ای نیست و رسیدن به چنین شرایطی هدفی بلندپروازانه است.
ایا حضور متخصصان محض در تیم قابل قبول است؟ در چنین شرایطی برای مثال یک نفر نیروی متخصص زبردستی در طراحی رابط کاربری است و در کنار او چند عضو دیگر هم با تخصص کمتری در تیم هستند در این مواقع ما تنها از بخشی از توانایی و تایم او استفاده میکنیم بهتر است از او در چندین تیم مختلف استفاده کنیم اما مراقب باشید پر کردن تایم او میتواند باعث بریدن او از سازمان باشد. راه دیگر تشویق نیروی متخصص زبردست برای ارتقا دانش نیروهای دیگر است تا وابستگی به او کمتر شود. در نهایت هدف ما تشکیل تیم چندتخصصی با اشتراک مهارت‌های نسبتا مشابه است اکثر اعضای تیم باید مهارت‌های تی شکل داشته باشند ولی احتمال حضور چند متخصص نیز در این ترکیب وجود دارد
۴- نگرش تفنگ‌دار
تاکیدی بر این است که کل تیم مسئول انجام کارهاست. موفقیت و شکست برای کل تیم است. اعضای تیم باید بپذیرند که با یکدیگر همکاری کنند تا تعهدات مشترکشان انجام شود. داشتن مهارت تی شکل این نگرش را تقویت و قابل انجام میکند و منحر میشود روی بیش از یک نوع وظیفه کار کنند. حتی اگر محدودیت‌های مهارتی وجود داشته باشد افراد باید بگونه‌ای کارشان را سازماندهی کنند که در طول اسپرینت فشار زیادی به هیچ یک از اعضا وارد نشود. برای مثال عقب انداختن آزمون‌ها تا پایان اسپرینت از این بابت که آزمونگر وقتش خالی شود منجر به شکست میشود
۵-ارتباطات گسترده
افراد تیم همانطور که با مالک و استاد در ارتباط هستند باید با همدیگر نیز در ارتباط باشند. تا اطلاعات ارزشمند به سرعت، با کارایی بالا و با کمترین هزینه بین آنها ردوبدل شود که منحر میشود تیم اسکرام فرصت بیشتری برای بازرسی و تطبیق بدست بیاورند که منحر به تصمیم گیری بهتر و سریعتر میشود. اطلاعات فرسوده می‌شوند و افزایش سرعت در اشتراک ان منحر میشود که تیم در مصرف منابع در مسیرهای نادرست جلوگیری کند. بیانیه چابک ارتباط رو در رو را رویکرد برتر میداند. با استفاده از تکنولوژی میتوان تیم‌های توزیع شده داشت اما در نهایت برای تیم‌های چندتخصصی ارتباط حضوری بهتر است و نمی‌توان آنرا جایگزین کرد و باعث حذف بوروکراسی و افزایش سرعت میشود همچنین باید تشریفات را کاهش داد برای مثال جهت ارتباط با مشتری نباید از سه لایه درخواست و تایید عبور کرد که غیرضروری است به یاد داشته باشید افزایش تعداد نفرات سربار ارتباطی بیشتر و گستردگی ارتباطات کاهش می‌یابد
۶- روابط شفاف
روابط شفاف، درک روشنی از آنچه که واقعا در حال وقوع است فراهم می‌سازد تا مانع غافلگیری افراد شود و به افزایش اعتماد بین اعضای تیم نیز کمک میکند. همیشه اعتقاد داشتم که ارتباط اعضای تیم باید بگونه‌ای باشد که با اصل کمترین غافلگیری مطابقت داشته باشد
۷- اندازه مناسب
اسکرام طرفدار تیم‌های کوچک است. بعنوان یک قاعده‌ی کلی قبول میکنیم که تیم‌های پنج تا نه نفره ایده آل هستند. نتایج تحقیقات نشان داده تیم‌های کوچک کارآمدترند
#scrum
@code_crafters
اعضای تیم توسعه باید تخصص‌های مختلفی داشته باشند، آنها در مجموع باید مهارت‌های لازم و کافی را داشته باشند. تیمی که بخوبی شکل گرفته باشد میتواند قلمی را از بک‌لاگ محصول بردارد و ویژگی با کیفیتی تولید کند که با تعریف انجام شده اسکرام مطابقت داشته باشد. تیم‌هایی که مهارت‌های مشابه دارند به روش سنتی در نهایت مجبورند که محصولات را دست به دست کنند که احتمال ایجاد اشتباهات پرهزینه و سوتفاهم دارد. وجود تیم‌هایی که که افراد آن دارای تخصص‌های مختلف هستند، تعداد ارجاع کارها را کمینه میکند. تنوع و چند تخصصی بودن تیم‌ها، مزایای متعددی دارد و منحر به نتایج بهتری میشود. اعضای هر تیم چند تخصصی، پیش زمینه و معلومات مختلفی دارند. هر عضو مجموعه‌ای از ابزارهای شناختی خود را برای حل مسئله همراه می‌آورد که میتواند شامل تفسیرهای مختلف از داده‌های یکسان، ابتکارها، راهبردهای حل مسئله مدل‌های ذهنی درباره عملکرد اشیا و سلیقه‌های مختلف در انتخاب رویکرد یا راهبردهای حل مسئله، مدل‌های ذهنی درباره عملکرد اشیا و سلیقه‌های مختلف در انتخاب رویکردها و راهکارها باشد که منجر به افزایش ارزش اقتصادی میشود تصویر اول در کامنت
سعی کنید ترکیب درستی از افراد با تجربه و تازه‌کار ایجاد کنید. وجود افراد با تجربه در کنار هم ممکن است موجب شلوغی غیرضروری و بی‌مورد گردد
مهارت‌های تی شکل T
تیم‌های توسعه انعطاف پذیر از اعضایی با مهارت‌های تی شکل تشکیل شده است. هر یک از اعضای تیم در تخصص اصلی خود عمیق و در برخی تخصص‌های دیگر گستردگی دارد. این افراد میتوانند در زمان‌های گلوگاه سازمان عملکرد جمعی بهتری از خود نشان داده و به تیم برای رفع مشکل پیش آمده کمک کنند. اینکه هر عضو تیم قادر به انجام هرکاری باشد، تصور واقع بینانه‌ای نیست و رسیدن به چنین شرایطی هدفی بلندپروازانه است.
ایا حضور متخصصان محض در تیم قابل قبول است؟ در چنین شرایطی برای مثال یک نفر نیروی متخصص زبردستی در طراحی رابط کاربری است و در کنار او چند عضو دیگر هم با تخصص کمتری در تیم هستند در این مواقع ما تنها از بخشی از توانایی و تایم او استفاده میکنیم بهتر است از او در چندین تیم مختلف استفاده کنیم اما مراقب باشید پر کردن تایم او میتواند باعث بریدن او از سازمان باشد. راه دیگر تشویق نیروی متخصص زبردست برای ارتقا دانش نیروهای دیگر است تا وابستگی به او کمتر شود. در نهایت هدف ما تشکیل تیم چندتخصصی با اشتراک مهارت‌های نسبتا مشابه است اکثر اعضای تیم باید مهارت‌های تی شکل داشته باشند ولی احتمال حضور چند متخصص نیز در این ترکیب وجود دارد
۴- نگرش تفنگ‌دار
تاکیدی بر این است که کل تیم مسئول انجام کارهاست. موفقیت و شکست برای کل تیم است. اعضای تیم باید بپذیرند که با یکدیگر همکاری کنند تا تعهدات مشترکشان انجام شود. داشتن مهارت تی شکل این نگرش را تقویت و قابل انجام میکند و منحر میشود روی بیش از یک نوع وظیفه کار کنند. حتی اگر محدودیت‌های مهارتی وجود داشته باشد افراد باید بگونه‌ای کارشان را سازماندهی کنند که در طول اسپرینت فشار زیادی به هیچ یک از اعضا وارد نشود. برای مثال عقب انداختن آزمون‌ها تا پایان اسپرینت از این بابت که آزمونگر وقتش خالی شود منجر به شکست میشود
۵-ارتباطات گسترده
افراد تیم همانطور که با مالک و استاد در ارتباط هستند باید با همدیگر نیز در ارتباط باشند. تا اطلاعات ارزشمند به سرعت، با کارایی بالا و با کمترین هزینه بین آنها ردوبدل شود که منحر میشود تیم اسکرام فرصت بیشتری برای بازرسی و تطبیق بدست بیاورند که منحر به تصمیم گیری بهتر و سریعتر میشود. اطلاعات فرسوده می‌شوند و افزایش سرعت در اشتراک ان منحر میشود که تیم در مصرف منابع در مسیرهای نادرست جلوگیری کند. بیانیه چابک ارتباط رو در رو را رویکرد برتر میداند. با استفاده از تکنولوژی میتوان تیم‌های توزیع شده داشت اما در نهایت برای تیم‌های چندتخصصی ارتباط حضوری بهتر است و نمی‌توان آنرا جایگزین کرد و باعث حذف بوروکراسی و افزایش سرعت میشود همچنین باید تشریفات را کاهش داد برای مثال جهت ارتباط با مشتری نباید از سه لایه درخواست و تایید عبور کرد که غیرضروری است به یاد داشته باشید افزایش تعداد نفرات سربار ارتباطی بیشتر و گستردگی ارتباطات کاهش می‌یابد
۶- روابط شفاف
روابط شفاف، درک روشنی از آنچه که واقعا در حال وقوع است فراهم می‌سازد تا مانع غافلگیری افراد شود و به افزایش اعتماد بین اعضای تیم نیز کمک میکند. همیشه اعتقاد داشتم که ارتباط اعضای تیم باید بگونه‌ای باشد که با اصل کمترین غافلگیری مطابقت داشته باشد
۷- اندازه مناسب
اسکرام طرفدار تیم‌های کوچک است. بعنوان یک قاعده‌ی کلی قبول میکنیم که تیم‌های پنج تا نه نفره ایده آل هستند. نتایج تحقیقات نشان داده تیم‌های کوچک کارآمدترند
#scrum
@code_crafters
👍4
از جمله نکات مثبت تیم‌های کوچک
تیمی بسیار کوچک است که افراد کافی برای انجام کار نداشته باشد یا اعضا بقدری کم باشند که نتوانند به شکلی کارا و موثر کار کنند. این مسیله به معنای ناسازگاری اسکرام برای کارهای بزرگ نیست منتها بجای یک تیم ۳۶ نفره چهار تیم ۹ نفره خواهیم داشت.شاخص بزرگی پروژه‌های اسکرام،بزرگی تیم توسعه نیست بلکه تعداد تیم‌های اسکرام است.تیم‌ها میتوانند با رویکرد اسکرام اسکرام‌ها تعامل و جلسات روزانه برگذار کنند که اعضای تیم‌ها باهم جمع می‌شوند
۸-دارای تمرکز و تعهد
اعضا باید روی هدف تیم تمرکز داشته و به آن متعهد باشند. تمرکز بدان معناست که هر یک از اعضای تیم مشارکتی فعال و توجه خود را معطوف به هدف تیم کرده باشند. متعهد نیز یعنی اعضای تیم چه شرایط خوب و چه بد خود را وقف هدف تیم کرده کنند.این دو موضوع هنگام کار بر روی یک محصول امکان پذیر است اما اگر فرد روی چند محصول کار کند باید زمان خود را تقسیم کند و این موجب کاهش تمرکز و تعهد میشود.انجام کار با کیفیت برای کسی که از محصولی به محصول دیگر پرش میکند دشوار است و دشوارتر از آن تعهد واقعی و همزمان به چندین محصول است.داده‌ها نشان میدهد بهره‌وری بر روی دو پروژه بهتر و بیشتر است و زمانی که یک پروژه موقتا متوقف شود کار بر روی دومی موجب میشود که فرد بیکار نباشد.همچنین این داده‌ها نشان میدهد که کار بر روی بیشتر از ۳ پروژه یک تصمیم اقتصادی اشتباه است چونکه بیشتر تایم صرف یادآوری و هماهنگی و ... می‌گردد.پس تکلیف متخصصانی که معمولا باید بر روی چندین محصول کار کنند چه میشود اجازه بدهید که او خود تصمیم بگیرد و متعهد شود به انجام کار و اگر تصمیم رد کردن او از دیدگاه کسب و کار قابل قبول نباشد چند راهکار وجود دارد:اول اینکه پروژه‌های کمتری بگیرید، افراد بیشتری استخدام کنید، روی افزایش مهارت سایر افراد کار کنید و یا ترکیبی از این موارد را انجام دهید
۹-کار با آهنگی پایدار
یکی از اصول اسکرام کار با آهنگی پایدار توسط اعضا است که موجب محصولاتی در کلاس جهانی تولید کنند و محیطی سالم و شاد داشته باشند. در توسعه ترتیبی یکپارچه سازی و آزمون تا اواخر کار به تعویق می‌افتد که خود منجر به حجم فشار کار در فازهای بعدی میشود که برای جبران کار از شب بیداری و استفاده از تعطیلی های خود بهره میبرند.این مورد را با اسکرام مقایسه کنید که تمامی موارد باید در هر اسپرینت صورت گیرد و با توجه به تعریف ما از «انجام شده» مطابقت داشته باشد. فشار کار در هر اسپرینت باید شبیه اسپرینت قبلی باشد تا تضمینی بر آهنگ پایدار کار باشد که نتیجه آن کار با بسته‌های بزرگ با سرعت خیلی زیاد و مخصوصا خیلی دیر به تیم محول نمیشود و منجر میشود که در اسکرام اضافه کاری کمتری رخ دهد و تیم خسته و بریده نشود
۱۰- دیرپا
برای اثربخشی اسکرام تیم لازم است،نه گروه
دیرپا به تیمی گفته میشود که اعضای آن برای مدت طولانی تا جاییکه صرفه اقتصادی داشته باشند حفظ شوند. تیم دیرپا در مقابل تیم تازه کار صرفه اقتصادی بیشتر و بهره وری بهتری دارند و شناخت قبلی بین اعضا اثر مثبتی بر کارایی و کیفیت خروجی‌های تیم داشته باشد که منجر به افزایش دستاوردهای کسب و کار میشود. گروهی از افراد که از قبل همدیگر نمی‌شناسند نیاز به زمان و هزینه است جهت یک تیم واقعی شدن است که باید مراحلی از قبیل شکل‌گیری، تلاطم، قاعده‌مندی، و اجرا را طی کنند تا یک تیم شوند. تیم کارآمد دارایی واقعی کسب و کار است. اعضا می‌دانند چگونه باهم کار کنند و اعتماد هم را جلب کنند همچنین این تیم اطلاعات تاریخی از جمله سرعت و برآورد مشترک دارند، تیم منحل شده یا دچار تغییرات اساسی شده این اطلاعات را ندارد. سازمانهایی که جابجایی زیاد دارند یک اصل اسکرام را فراموش کرده‌اند مبنای چابکی تیم است یکی از ارزش‌های اصلی چابکی «افراد و تعاملات» است.سازمانها بهتر است سیاستی در ویش بگیرند که هسته تیم تا جای ممکن حفظ شود و بجای انتقال افراد تیم از محصولی به محصولی دیگر جابجا شود، جابجایی تیم خوش ترکیب صرفه اقتصادی بیشتری دارد تا افراد(انحلال تیم‌های که طبق انتظار یا بد کارند صرفه اقتصادی دارد) تحزیه تیم اسکرام خوب جهت گسترش اسکرام در سازمان وحود دارد. استراتژی «تقسیم و کاشتن»
#scrum
@code_crafters
-تنبلی اجتماعی کاهش می‌یابد.این تصور که یکنفر هست کارها را به هرحال انجام دهد
-تعاملات سازنده بیشتر است
-زمان کمتری صرف هماهنگی کارها میشود
-اعضای تیم‌های کوچک از سایر هم تیمی‌های خود رضایت بیشتری دارند
-احتمال انجام تخصصی بیش از حد بعضی کارها کاهش می‌یابد
تیمی بسیار کوچک است که افراد کافی برای انجام کار نداشته باشد یا اعضا بقدری کم باشند که نتوانند به شکلی کارا و موثر کار کنند. این مسیله به معنای ناسازگاری اسکرام برای کارهای بزرگ نیست منتها بجای یک تیم ۳۶ نفره چهار تیم ۹ نفره خواهیم داشت.شاخص بزرگی پروژه‌های اسکرام،بزرگی تیم توسعه نیست بلکه تعداد تیم‌های اسکرام است.تیم‌ها میتوانند با رویکرد اسکرام اسکرام‌ها تعامل و جلسات روزانه برگذار کنند که اعضای تیم‌ها باهم جمع می‌شوند
۸-دارای تمرکز و تعهد
اعضا باید روی هدف تیم تمرکز داشته و به آن متعهد باشند. تمرکز بدان معناست که هر یک از اعضای تیم مشارکتی فعال و توجه خود را معطوف به هدف تیم کرده باشند. متعهد نیز یعنی اعضای تیم چه شرایط خوب و چه بد خود را وقف هدف تیم کرده کنند.این دو موضوع هنگام کار بر روی یک محصول امکان پذیر است اما اگر فرد روی چند محصول کار کند باید زمان خود را تقسیم کند و این موجب کاهش تمرکز و تعهد میشود.انجام کار با کیفیت برای کسی که از محصولی به محصول دیگر پرش میکند دشوار است و دشوارتر از آن تعهد واقعی و همزمان به چندین محصول است.داده‌ها نشان میدهد بهره‌وری بر روی دو پروژه بهتر و بیشتر است و زمانی که یک پروژه موقتا متوقف شود کار بر روی دومی موجب میشود که فرد بیکار نباشد.همچنین این داده‌ها نشان میدهد که کار بر روی بیشتر از ۳ پروژه یک تصمیم اقتصادی اشتباه است چونکه بیشتر تایم صرف یادآوری و هماهنگی و ... می‌گردد.پس تکلیف متخصصانی که معمولا باید بر روی چندین محصول کار کنند چه میشود اجازه بدهید که او خود تصمیم بگیرد و متعهد شود به انجام کار و اگر تصمیم رد کردن او از دیدگاه کسب و کار قابل قبول نباشد چند راهکار وجود دارد:اول اینکه پروژه‌های کمتری بگیرید، افراد بیشتری استخدام کنید، روی افزایش مهارت سایر افراد کار کنید و یا ترکیبی از این موارد را انجام دهید
۹-کار با آهنگی پایدار
یکی از اصول اسکرام کار با آهنگی پایدار توسط اعضا است که موجب محصولاتی در کلاس جهانی تولید کنند و محیطی سالم و شاد داشته باشند. در توسعه ترتیبی یکپارچه سازی و آزمون تا اواخر کار به تعویق می‌افتد که خود منجر به حجم فشار کار در فازهای بعدی میشود که برای جبران کار از شب بیداری و استفاده از تعطیلی های خود بهره میبرند.این مورد را با اسکرام مقایسه کنید که تمامی موارد باید در هر اسپرینت صورت گیرد و با توجه به تعریف ما از «انجام شده» مطابقت داشته باشد. فشار کار در هر اسپرینت باید شبیه اسپرینت قبلی باشد تا تضمینی بر آهنگ پایدار کار باشد که نتیجه آن کار با بسته‌های بزرگ با سرعت خیلی زیاد و مخصوصا خیلی دیر به تیم محول نمیشود و منجر میشود که در اسکرام اضافه کاری کمتری رخ دهد و تیم خسته و بریده نشود
۱۰- دیرپا
برای اثربخشی اسکرام تیم لازم است،نه گروه
تیم: مجموعه‌ای از افراد با تخصص‌های مختلف که چشم اندازی مشترک و برای دستیابی به آن باهم کار میکنند
گروه: مجموعه از افراد که عنوان مشترکی دارند وجه اشتراک دیگری غیر از نام ندارند و نمی‌توانند مسئولیت تیم توسعه اسکرام را انجام دهند
دیرپا به تیمی گفته میشود که اعضای آن برای مدت طولانی تا جاییکه صرفه اقتصادی داشته باشند حفظ شوند. تیم دیرپا در مقابل تیم تازه کار صرفه اقتصادی بیشتر و بهره وری بهتری دارند و شناخت قبلی بین اعضا اثر مثبتی بر کارایی و کیفیت خروجی‌های تیم داشته باشد که منجر به افزایش دستاوردهای کسب و کار میشود. گروهی از افراد که از قبل همدیگر نمی‌شناسند نیاز به زمان و هزینه است جهت یک تیم واقعی شدن است که باید مراحلی از قبیل شکل‌گیری، تلاطم، قاعده‌مندی، و اجرا را طی کنند تا یک تیم شوند. تیم کارآمد دارایی واقعی کسب و کار است. اعضا می‌دانند چگونه باهم کار کنند و اعتماد هم را جلب کنند همچنین این تیم اطلاعات تاریخی از جمله سرعت و برآورد مشترک دارند، تیم منحل شده یا دچار تغییرات اساسی شده این اطلاعات را ندارد. سازمانهایی که جابجایی زیاد دارند یک اصل اسکرام را فراموش کرده‌اند مبنای چابکی تیم است یکی از ارزش‌های اصلی چابکی «افراد و تعاملات» است.سازمانها بهتر است سیاستی در ویش بگیرند که هسته تیم تا جای ممکن حفظ شود و بجای انتقال افراد تیم از محصولی به محصولی دیگر جابجا شود، جابجایی تیم خوش ترکیب صرفه اقتصادی بیشتری دارد تا افراد(انحلال تیم‌های که طبق انتظار یا بد کارند صرفه اقتصادی دارد) تحزیه تیم اسکرام خوب جهت گسترش اسکرام در سازمان وحود دارد. استراتژی «تقسیم و کاشتن»
#scrum
@code_crafters
👍4
ساختارهای تیم اسکرام
مرور
اگر در حال توسعه یک پروژه کوچک هستید فقط کافیست تیم چندتخصصی به همراه یک مالک و استاد داشته باشید. اما کار بر روی پروژه‌های بزرگ و سازمانها با نیروی زیاد نیاز به ایجاد هماهنگی بین تیم‌ها دارد چونکه کار اشتراک صورت میگیرد. نحوه سازماندهی این تیم‌ها که کارایی بالایی داشته باشند رو با در نظر گرفتن چند عامل پاسخ می‌دهیم. اول اینکه از بین تیم‌های ویژگی محور یا مولفه محور کدام یک برای شما مناسب است دوم اینکه برای هماهنگ کردن فعالیت‌های بین چند تیم از چه رویکردهایی میتوانید استفاده کنید
مقایسه تیم‌های ویژگی محور با مولفه محور
تیم ویژگی محور تیمی چندتخصصی و چند مولفه‌ای است که میتواند ویژگی‌ها را از یک‌لاگ برداشته و تکمیل نماید، در حالیکه تیم مولفه محور مسئول توسعه یک مولفه یا زیرسیستم است و فقط میتواند قسمتی از ویژگی درخواستی و نه همه آن را تکمیل نماید.
به تیم‌های مولفه محور، تیم‌های دارایی محور یا تیم‌های زیرسیستم هم گفته میشود که از افرادی با تخصص‌های مشابه و مهارتی ویژه تشکیل شده‌اند. گزارش خود را به یک مدیر وظیفه‌ای گزارش داده و بعنوان منبعی مشترک و متمرکز برای سایر تیم‌ها کار میکند. نمونه این تیم‌ها واحد متمرکز «طراحی تجربه کاربر» است که رابط کاربر را برای سایر تیم‌ها طراحی میکند. اسکرام طرفدار تیم‌های ویژگی محور است اما سازمانها علاقه به مولفه محور دارند با این دیدگاه که یک تیم متخصص توسعه قسمت خود را برعهده گرفته و مسئولیت آن را برعهده بگیرد تا تیم چندتخصصی که ممکن است کد را بهم بزند. تصویر اول در کامنت
در این نمونه تیم ویژگی محور وجود ندارد لذا اقلام از بک‌لاگ برداشته شده و به تیم‌های مولفه محور سپرده میشود. تقسیم بندی توسط تیم‌های مولفه محور به صورت دسته جمعی یا احتمالا توسط یک معمار انجام میشود. سپس هر قلم در بک‌لاگ محصول یکی از تیم‌ها قرار میگیرد و شروع به اجرای بک‌لاگ میکنند اما تکمیل نمی‌کنند. تکمیل ان با روش اسکرام اسکرام‌ها در نهایت تکمیل می‌گرد. چنین رویکردی که یک کانال برای ورود درخواست‌های محصول به تیم‌های مولفه محور وجود داشته باشد. تجربه نشان داده است که سازمانها بعد از روی زمین ماندن ویژگی پی میبرند که چنین تیم‌هایی کاربرد ندارند. تعداد نقاط شکست در تیم‌های مولفه محور به اندازه تعداد تیم‌های موجود است برخلاف آن در تیم‌های ویژگی محور یک نقطه شکست وجود دارد. در تیم‌های مولفه محور نمی‌توان زمان قطعی ارائه داد و انجام شدن یا نشدن یک ویژگی را مشخص کرد. در تیم‌های ویژگی محور خوش ترکیب باشند و به مرور زمان مالکیت مشترکی نسبت به کد پیدا کنند و بتوانند در قالب یک گروه به متولیان قابل اعتمادی برای کد تبدیل شوند، مشکلاتی از قبیل بهم‌ریختگی کد و بدهی فنی و ... برطرف خواهد شد. یکی از رویکردهای موقتی در دستیابی به تیم‌های ویژگی محور که مالکیت مشترکی بر کد داشته باشند در تصویر دوم در کامنت می‌بینید. در اینجا یک تیم ویژگی محور داریم که میتواند اقلام با ارزش را از بک لاگ برداشته و تکمیل نماید، مسئولیت و مدیریت جزییات برعهده این تیم است. تیم‌های مولفه محور مورد اعتماد همچنان باقی می‌مانند تا به حفظ یکپارچگی مولفه‌ها کمک کنند. بک‌لاگ آنها حاوی کارهای فنی است در هر یک از مولفه‌ها انجام شوند. از هر تیم مولفه محور یکنفر در تیم‌ویژگی محور حصگضور دارد. این موجب رویکرد بذرافشان و دروگر میشود. فرد در تیم ویژگی محور دانش خود را به تیم انتقال میدهد جهت مالکیت مشترک کد (بذرافشانی)، تیم مولفه محور هم تغییرات مورد نیاز تیم ویژگی محور گردآوری کرده و با همکاران خود در خصوص آن گفتگو کرده و هرکدام نیز به نوبه خود از تیم‌های دیگر گرداوری کرده‌اند. تیم مولفه محور مطمئن میشود که تغییرات در مولفه‌ها برای رفع نیازهای تیم‌های ویژگی محور انجام خواهد شدهماهنگ و تحت کنترل، که منجر به تغییرات به شیوه منسجم و بدون تعارض تا از یکپارچگی مفهومی آن مطمئن گردند. یکی از مشکلات در شرکتهای بزرگ برای مثال که ۵۰ تیم مولفه محور دارند در چنین مواقعی چندتیم ویژگی محور ساخته میشود و اعضای هر تیم متشکل از اعضای مولفه‌هایی است که بیشتر باهم در ارتباط هستند و جهت هماهنگی بین آنها از تیم‌های چندگانه بهره میبریم، یکی دیگر از مشکلات این است که ممکن است یکی از تیم‌های مولفه محور تنها ۴ عضو داشته باشد که نمیتوانیم آنها را بشکنیم در این مواقع افراد با مهارت بالاتر استخدام میکنیم یا تعداد محصولات در حال توسعه را کاهش می‌دهیم یا اموزش مولفه به تعداد بیشتر یا بهتر از همه ارتقا سطح مالکیت مشترک کد. هیچ راه حل جامعی برای ترکیب دو تیم وجود ندارد اما بهتر است تیم ویژگی محور داشته باشیم و در کنارش تیم مولفه محور به شرط توجیه اقتصادی داشتن اما تجربه نشان داده اکثر سازمانها خلاف ان را انجام می‌دهند
#scrum
@code_crafters
مرور
اگر در حال توسعه یک پروژه کوچک هستید فقط کافیست تیم چندتخصصی به همراه یک مالک و استاد داشته باشید. اما کار بر روی پروژه‌های بزرگ و سازمانها با نیروی زیاد نیاز به ایجاد هماهنگی بین تیم‌ها دارد چونکه کار اشتراک صورت میگیرد. نحوه سازماندهی این تیم‌ها که کارایی بالایی داشته باشند رو با در نظر گرفتن چند عامل پاسخ می‌دهیم. اول اینکه از بین تیم‌های ویژگی محور یا مولفه محور کدام یک برای شما مناسب است دوم اینکه برای هماهنگ کردن فعالیت‌های بین چند تیم از چه رویکردهایی میتوانید استفاده کنید
مقایسه تیم‌های ویژگی محور با مولفه محور
تیم ویژگی محور تیمی چندتخصصی و چند مولفه‌ای است که میتواند ویژگی‌ها را از یک‌لاگ برداشته و تکمیل نماید، در حالیکه تیم مولفه محور مسئول توسعه یک مولفه یا زیرسیستم است و فقط میتواند قسمتی از ویژگی درخواستی و نه همه آن را تکمیل نماید.
به تیم‌های مولفه محور، تیم‌های دارایی محور یا تیم‌های زیرسیستم هم گفته میشود که از افرادی با تخصص‌های مشابه و مهارتی ویژه تشکیل شده‌اند. گزارش خود را به یک مدیر وظیفه‌ای گزارش داده و بعنوان منبعی مشترک و متمرکز برای سایر تیم‌ها کار میکند. نمونه این تیم‌ها واحد متمرکز «طراحی تجربه کاربر» است که رابط کاربر را برای سایر تیم‌ها طراحی میکند. اسکرام طرفدار تیم‌های ویژگی محور است اما سازمانها علاقه به مولفه محور دارند با این دیدگاه که یک تیم متخصص توسعه قسمت خود را برعهده گرفته و مسئولیت آن را برعهده بگیرد تا تیم چندتخصصی که ممکن است کد را بهم بزند. تصویر اول در کامنت
در این نمونه تیم ویژگی محور وجود ندارد لذا اقلام از بک‌لاگ برداشته شده و به تیم‌های مولفه محور سپرده میشود. تقسیم بندی توسط تیم‌های مولفه محور به صورت دسته جمعی یا احتمالا توسط یک معمار انجام میشود. سپس هر قلم در بک‌لاگ محصول یکی از تیم‌ها قرار میگیرد و شروع به اجرای بک‌لاگ میکنند اما تکمیل نمی‌کنند. تکمیل ان با روش اسکرام اسکرام‌ها در نهایت تکمیل می‌گرد. چنین رویکردی که یک کانال برای ورود درخواست‌های محصول به تیم‌های مولفه محور وجود داشته باشد. تجربه نشان داده است که سازمانها بعد از روی زمین ماندن ویژگی پی میبرند که چنین تیم‌هایی کاربرد ندارند. تعداد نقاط شکست در تیم‌های مولفه محور به اندازه تعداد تیم‌های موجود است برخلاف آن در تیم‌های ویژگی محور یک نقطه شکست وجود دارد. در تیم‌های مولفه محور نمی‌توان زمان قطعی ارائه داد و انجام شدن یا نشدن یک ویژگی را مشخص کرد. در تیم‌های ویژگی محور خوش ترکیب باشند و به مرور زمان مالکیت مشترکی نسبت به کد پیدا کنند و بتوانند در قالب یک گروه به متولیان قابل اعتمادی برای کد تبدیل شوند، مشکلاتی از قبیل بهم‌ریختگی کد و بدهی فنی و ... برطرف خواهد شد. یکی از رویکردهای موقتی در دستیابی به تیم‌های ویژگی محور که مالکیت مشترکی بر کد داشته باشند در تصویر دوم در کامنت می‌بینید. در اینجا یک تیم ویژگی محور داریم که میتواند اقلام با ارزش را از بک لاگ برداشته و تکمیل نماید، مسئولیت و مدیریت جزییات برعهده این تیم است. تیم‌های مولفه محور مورد اعتماد همچنان باقی می‌مانند تا به حفظ یکپارچگی مولفه‌ها کمک کنند. بک‌لاگ آنها حاوی کارهای فنی است در هر یک از مولفه‌ها انجام شوند. از هر تیم مولفه محور یکنفر در تیم‌ویژگی محور حصگضور دارد. این موجب رویکرد بذرافشان و دروگر میشود. فرد در تیم ویژگی محور دانش خود را به تیم انتقال میدهد جهت مالکیت مشترک کد (بذرافشانی)، تیم مولفه محور هم تغییرات مورد نیاز تیم ویژگی محور گردآوری کرده و با همکاران خود در خصوص آن گفتگو کرده و هرکدام نیز به نوبه خود از تیم‌های دیگر گرداوری کرده‌اند. تیم مولفه محور مطمئن میشود که تغییرات در مولفه‌ها برای رفع نیازهای تیم‌های ویژگی محور انجام خواهد شدهماهنگ و تحت کنترل، که منجر به تغییرات به شیوه منسجم و بدون تعارض تا از یکپارچگی مفهومی آن مطمئن گردند. یکی از مشکلات در شرکتهای بزرگ برای مثال که ۵۰ تیم مولفه محور دارند در چنین مواقعی چندتیم ویژگی محور ساخته میشود و اعضای هر تیم متشکل از اعضای مولفه‌هایی است که بیشتر باهم در ارتباط هستند و جهت هماهنگی بین آنها از تیم‌های چندگانه بهره میبریم، یکی دیگر از مشکلات این است که ممکن است یکی از تیم‌های مولفه محور تنها ۴ عضو داشته باشد که نمیتوانیم آنها را بشکنیم در این مواقع افراد با مهارت بالاتر استخدام میکنیم یا تعداد محصولات در حال توسعه را کاهش می‌دهیم یا اموزش مولفه به تعداد بیشتر یا بهتر از همه ارتقا سطح مالکیت مشترک کد. هیچ راه حل جامعی برای ترکیب دو تیم وجود ندارد اما بهتر است تیم ویژگی محور داشته باشیم و در کنارش تیم مولفه محور به شرط توجیه اقتصادی داشتن اما تجربه نشان داده اکثر سازمانها خلاف ان را انجام می‌دهند
#scrum
@code_crafters
👍3
ایجاد هماهنگی بین چند تیم
با افزایش تعداد اعضای تیم‌های توسعه ابعاد استفاده از اسکرام افزایش نمی‌یابد بلکه باید تعداد تیم‌هایی که اندازه مناسبی دارند افزایش یابد. داشتن بیش از یک تیم چالش هماهنگی ایجاد میکند که دو رویکرد برا آن داریم «اسکرام اسکرام‌ها» و «قطار انتشار»
اسکرام اسکرام‌ها
در اسکرام روزانه اعضای تیم حضور دارند. یکی از روش‌های متداول هماهنگی بین چند تیم اسکرام اسکرام‌ها (SoS) این است که از هر تیم یکنفر نماینده که میتواند با بقیه ارتباط گرفتن و کارها را گزارش دهد در جلسه SoS حضور یابد (بهتر است این نفر ثابت باشد)، در برخی تیم‌ها استاد مشترک چندتیم را هم به همراه نماینده می‌فرستند اما مراقب هستند تعداد زیاد نشود تعیین استاد اسکرام اسکرام‌ها هم بسیار منطقی است. جلسات مربوط به ان چند روز در هفته برگذار میشود نه هر روزه و نحوه برگذاری آن هم رویکردهای خاص خودش را دارد اما سوالات زیر مطرح است
جلسات آن ۱۵ دقیقه است و بحث در خصوص مسایل را بعد از ان انجام می‌دهند تا افراد علاقمند و مورد نیاز حضور داشته باشند. اگر گروه‌های مختلف در اسکرام اسکرام را خوشه بندی کنیم.
قطار انتشار
رویکردی جهت همسو کردن چشم انداز، برنامه ریزی و ارتباط بین تیم‌ها به کمک ایجاد هماهنگی بین آنها و بر اساس راه اندازی آهنگی مشترک است که هدف آن ایجاد روندی سریع و منعطف برای محصولات بزرگ است. تمام تیم‌ها در این رویکرد موظف هستند که کار خود را در زمانی مشخص تحویل دهند، که قواعدی دارد:
قطار انتشار شامل سبد محصول و سطوح انتشار میشود که دارای سه سطح است: بک لاگ سبد محصول(اپیک‌هایی که مالکیت آن با مدیریت آن است)، بک لاگ برنامه(ویژگی‌هایی که مالکیت آن با مدیرت آن است)، بک لاک تیم(داستان‌های کاربر قابل انجام در یک اسپرینت که با ماک محصول است)می‌باشد تصویر اول در کامنت
۹ تیم در قالب ۳ خوشه که با اسکرام اسکرام‌ها پیش می‌روند.در هر زمان ممکن باید ازمون و یکپارچه سازی سیستم به نحوی انجام شود که همه ویژگی‌های ویژگی را در بر بگیرد. مدت اسپرینت برای تمام تیم‌ها یکسان است که موجب ایجاد هماهنگی در تمامی تیم‌ها میشود. هر PSI (هر انتشار بعد از تعداد معینی اسپرینت که معمولا ۴ اسپرینت است) آماده میشود. این زمان بندی به سازمان کمک میکند هماهنگی اتی خود را انجام دهد که در زمان تعیین شده انتشار میتواند:
را داشته باشد
هر قطار انتشار با برگزاری جلسه برنامه ریزی انتشار آغاز میشود که همه تیم‌هایی که روی PSI کار میکنند در ان حاضرند.
در یک اتاق بزرگ مالک ارشد PSI را ارائه داده و هر تیم کنار هم نشسته و تیم‌هایی که در یک گروه ویژگی قرار دارند نزدیک هم می‌نشینند تیم‌های حاضر در یک گروه دور هم جمع شده و مالکان آنها تصویر مربوط به به خود برای انتشار بعدی را ارائه می‌دهند و تیم‌ها نگاشت اسپرینت (قراردادن ویژگی‌ها در اسپرینت‌ها) میکنند جهت هماهنگی بیشتر هرزگاهی یکی از اعضای تیم به تیم‌های دیگر رفته و از انها میپرسد آیا میتوانند این ویژگی را در همین قطار انتشار انجام دهند و با دریافت تایید تیم متعهد به انجام آن میشود. جهت اطمینان از درک بیشتر قطار انتشار مالک ارشد، مالکان گروه ویژگی و معماران به میان تیم‌های دیگر می‌روند البته تیم‌ها نیز میتوانند درخواست کمک از آنها را ارائه دهند. پس از پایان اسپرینت‌ها به نقطه انتشار PSI میرسیم. در این نقطه فعالیت بازرسی و تطبیق در سطح قطار انتشار را انجام می‌دهیم اولین فعالیت بازبینی کل بار قطار انتشار و دومی بازاندیشی در سطح قطار انتشار است
#scrum
@code_crafters
با افزایش تعداد اعضای تیم‌های توسعه ابعاد استفاده از اسکرام افزایش نمی‌یابد بلکه باید تعداد تیم‌هایی که اندازه مناسبی دارند افزایش یابد. داشتن بیش از یک تیم چالش هماهنگی ایجاد میکند که دو رویکرد برا آن داریم «اسکرام اسکرام‌ها» و «قطار انتشار»
اسکرام اسکرام‌ها
در اسکرام روزانه اعضای تیم حضور دارند. یکی از روش‌های متداول هماهنگی بین چند تیم اسکرام اسکرام‌ها (SoS) این است که از هر تیم یکنفر نماینده که میتواند با بقیه ارتباط گرفتن و کارها را گزارش دهد در جلسه SoS حضور یابد (بهتر است این نفر ثابت باشد)، در برخی تیم‌ها استاد مشترک چندتیم را هم به همراه نماینده می‌فرستند اما مراقب هستند تعداد زیاد نشود تعیین استاد اسکرام اسکرام‌ها هم بسیار منطقی است. جلسات مربوط به ان چند روز در هفته برگذار میشود نه هر روزه و نحوه برگذاری آن هم رویکردهای خاص خودش را دارد اما سوالات زیر مطرح است
-تیم من از آخرین جلسه قبلی چه کاری انجام داده است که ممکن است تیم‌های دیگر را تحت تاثیر قرار دهد؟
-تیم من تا جلسه بعدی چه کاری انجام میدهد که احتمالا تیم‌های دیگر را تحت تاثیر قرار میدهد؟
-تیم من چه مشکلاتی دارد و برای حل آنها ممکن است به کمک تیم‌های دیگر نیاز داشته باشد؟
جلسات آن ۱۵ دقیقه است و بحث در خصوص مسایل را بعد از ان انجام می‌دهند تا افراد علاقمند و مورد نیاز حضور داشته باشند. اگر گروه‌های مختلف در اسکرام اسکرام را خوشه بندی کنیم.
قطار انتشار
رویکردی جهت همسو کردن چشم انداز، برنامه ریزی و ارتباط بین تیم‌ها به کمک ایجاد هماهنگی بین آنها و بر اساس راه اندازی آهنگی مشترک است که هدف آن ایجاد روندی سریع و منعطف برای محصولات بزرگ است. تمام تیم‌ها در این رویکرد موظف هستند که کار خود را در زمانی مشخص تحویل دهند، که قواعدی دارد:
-تاریخ‌های برنامه ریزی و تاریخ انتشارهای متناوب و دوره‌ای راهکار تعیین شده باشند
-مدت تکرار در تیم‌ها یکسان است
-مایلستونهای میانی و کلی با هدفی تعیین شده باشند
-یکپارچه سازی علاوه در سطح ویژگی و مولفه، در سطح کلان یا سیستم نیز انجام شود
-بخش‌های قابل انتشار که به آن PSI گفته میشود در فواصل زمانی ۳ یا ۴ ماه جهت نمایش برای مشتری، تضمین کیفیت در سطح سیستم و بازنگری داخلی آماده باشند
-از تکرار تثبیت جهت کاهش بدهی فنی و اختصاص زمان برای ازمون و اعتبارسنجی خاصی در انتشار استفاده شود
-جهت کار تیم‌ها در بستری یکسان مولفه‌های زیرساختی مشخصی همچو رابط‌ها، بسته‌های توسعه سیستم، ابزارهای نصب و محوزدهی، تحربه کاربر و خدمات پایه اینترنتی در دستور کار قرار گیرند
قطار انتشار شامل سبد محصول و سطوح انتشار میشود که دارای سه سطح است: بک لاگ سبد محصول(اپیک‌هایی که مالکیت آن با مدیریت آن است)، بک لاگ برنامه(ویژگی‌هایی که مالکیت آن با مدیرت آن است)، بک لاک تیم(داستان‌های کاربر قابل انجام در یک اسپرینت که با ماک محصول است)می‌باشد تصویر اول در کامنت
۹ تیم در قالب ۳ خوشه که با اسکرام اسکرام‌ها پیش می‌روند.در هر زمان ممکن باید ازمون و یکپارچه سازی سیستم به نحوی انجام شود که همه ویژگی‌های ویژگی را در بر بگیرد. مدت اسپرینت برای تمام تیم‌ها یکسان است که موجب ایجاد هماهنگی در تمامی تیم‌ها میشود. هر PSI (هر انتشار بعد از تعداد معینی اسپرینت که معمولا ۴ اسپرینت است) آماده میشود. این زمان بندی به سازمان کمک میکند هماهنگی اتی خود را انجام دهد که در زمان تعیین شده انتشار میتواند:
-تصمیم گیری بر اساس منافع کسب و کار جهت استقرار PSI
-فرصت برای تایید صحت یکپارچگی و آزمون کارهای گروه‌های مختلف
-درخواست بازنگری داخلی
را داشته باشد
هر قطار انتشار با برگزاری جلسه برنامه ریزی انتشار آغاز میشود که همه تیم‌هایی که روی PSI کار میکنند در ان حاضرند.
در یک اتاق بزرگ مالک ارشد PSI را ارائه داده و هر تیم کنار هم نشسته و تیم‌هایی که در یک گروه ویژگی قرار دارند نزدیک هم می‌نشینند تیم‌های حاضر در یک گروه دور هم جمع شده و مالکان آنها تصویر مربوط به به خود برای انتشار بعدی را ارائه می‌دهند و تیم‌ها نگاشت اسپرینت (قراردادن ویژگی‌ها در اسپرینت‌ها) میکنند جهت هماهنگی بیشتر هرزگاهی یکی از اعضای تیم به تیم‌های دیگر رفته و از انها میپرسد آیا میتوانند این ویژگی را در همین قطار انتشار انجام دهند و با دریافت تایید تیم متعهد به انجام آن میشود. جهت اطمینان از درک بیشتر قطار انتشار مالک ارشد، مالکان گروه ویژگی و معماران به میان تیم‌های دیگر می‌روند البته تیم‌ها نیز میتوانند درخواست کمک از آنها را ارائه دهند. پس از پایان اسپرینت‌ها به نقطه انتشار PSI میرسیم. در این نقطه فعالیت بازرسی و تطبیق در سطح قطار انتشار را انجام می‌دهیم اولین فعالیت بازبینی کل بار قطار انتشار و دومی بازاندیشی در سطح قطار انتشار است
#scrum
@code_crafters
❤3
مدیران
مرور
یکی از ترس‌های مانع اجرای اسکرام از دست دادن کنترل مدیریتی است، اسکرام به مدیریت اشاره نکرده اما این به این معنا نیست که سیستم مدیریتی در آن وجود ندارد. در هر سازمان اسکرامی مدیران کماکان مسئولیت‌های مهمی برعهده دارند. مدیران وظیفه ساماندهی و پرورش تیم‌ها، هماهنگی و تطبیق با محیط بیرونی و مدیریت جریان ایجاد ارزش را برعهده دارند. تصویر اول در کامنت
ساماندهی تیم‌ها
مدیران با فرآیندی که شامل تعیین مرزهای، تعیین اهداف شفاف، شکل دادن تیم‌ها، تغییر ترکیب و توانمندسازی آنها تیم ها را سازماندهی میکنند
پرورش تیم
بعد از تشکیل تیم مدیران باید روی به افراد انگیزه و انرژی بدهند بر روی توسعه توانایی‌ها و شایستگی‌های انها کار کنند، تیم را در حوزه وظیفه‌ای رهبری و یکپارچگی و انسجام آن را حفظ کنند
#scrum
@code_crafters
مرور
یکی از ترس‌های مانع اجرای اسکرام از دست دادن کنترل مدیریتی است، اسکرام به مدیریت اشاره نکرده اما این به این معنا نیست که سیستم مدیریتی در آن وجود ندارد. در هر سازمان اسکرامی مدیران کماکان مسئولیت‌های مهمی برعهده دارند. مدیران وظیفه ساماندهی و پرورش تیم‌ها، هماهنگی و تطبیق با محیط بیرونی و مدیریت جریان ایجاد ارزش را برعهده دارند. تصویر اول در کامنت
ساماندهی تیم‌ها
مدیران با فرآیندی که شامل تعیین مرزهای، تعیین اهداف شفاف، شکل دادن تیم‌ها، تغییر ترکیب و توانمندسازی آنها تیم ها را سازماندهی میکنند
-تعیین مرزها
تیم خودسازمانده میداند که بدون مدیر چگونه مسئولیت خود را زیر نظر مدیران انجام دهد. اما بندرت پیش می‌آید در خصوص تولید چه محصولی تصمیم بگیرد، این برعهده مدیران است و تیم در مرزی محدود فعالیت و خودسازمانده است. برای مثال سازمانی که سیستم حسابداری انجام میدهد مدیران تعیین میکنند چه نوع برنامه‌ای باشد و برای تعیین مرزها یکی از دو گزینه را انتخاب میکنند: تیم توسعه محصول را به تیم استقرار تحویل میدهد تا بعد از اسپرینت مستقر شود یا تیم استقرار ان را بعنوان بخشی از اسپرینت انجام دهد
-تعیین اهداف شفاف
مدیران تعیین کننده اهداف تیم هستند که موجب میشود تیم انگیزه و جهت بگیرد. مالک مسئول تعریف دقیقتر آن است
-تشکیل تیم
مدیران تعیین میکنند چه کسی عضو تیم باشد و ترکیب تیم را مشخص میکنند تیم تنها مشارکت میکند در مصاحبه با نفر جدید اما تصمیم نهایی را مدیران متناسب با نیازها و محدودیت‌های کسب و کار میگیرن. مدیران وظیفه‌ای نمایندگی بخش‌های مختلف فنی یا گروه‌های تخصصی را برعهده دارند و به کمک همدیگر، اعضای تیم‌های چندتخصصی را انتخاب میکنند که ساختار تی شکل دارند. تصویر دوم در کامنت
-تغییر ترکیب تیم
اگر مدیران به این نتیجه برسند که با تغییر ترکیب تیم شرایط و کارایی تیم یا سازمان بهتر میشود موظفند که ترکیب را تغیرر دهند. برای مثال فرد ناسازگار در تیم ابتدا گروه سعی میکنند او را بهتر کنند در غیر اینصورت استاد این تلاش را میکند و در غیر این صورت مدیری که فرد به او مستقیم گزارش میدهد را مطلع میکنند و او با هماهنگی منابع انسانی سعی در بهبود او با توجیه بچیا جابجایی انجام می‌دهند در غیر این صورت سازمان را ترک میکند. استاد و اعضا توان عزل و نصب ندارند اما در آن مشارکت میکنند. مورد دیگر فردی با توانایی بالاست که برای انتقال دانش خود بین تیم‌های مختلف جابجا میشود در این خصوص مدیران باید دقت کنند چون جابجایی روی هردو تیم تاثیر می‌گذارد
-تفویض اختیار
مدیران برای حفظ خودسازماندهی تیم برخی اختیارات مدیریتی را با تعیین سطح اختیارات به آنها می‌سپارد که در هفت سطح می‌باشد تصویر سوم در کامنت، مدیران بعد از سپردن اختیارات به تیم اجازه ندارند خلاف آن تصمیم بگیرند. مدیران باید کمک کنند که اعضای تیم به یکدیگر اعتماد کنند. لذا نیازمند مشخص کردن محدوده مناسب فعالیتی استکه منجر به اعتماد بین اعضا میشود. از سوی دیگر چون تیم‌ها مدیری ندارند که آنها را موظف به انجام کار کنند، باید به اعضا کمک کنند تا اخمیت انجام تعهدات خود را داشته باشند
پرورش تیم
بعد از تشکیل تیم مدیران باید روی به افراد انگیزه و انرژی بدهند بر روی توسعه توانایی‌ها و شایستگی‌های انها کار کنند، تیم را در حوزه وظیفه‌ای رهبری و یکپارچگی و انسجام آن را حفظ کنند
-انرژی دادن به افراد
مدیران باید مدام به دنبال راه‌هایی برای افزایش انگیزه افراد باشند تا کارها بصورت فوق العاده انجام گیرند. در سایه مدیریت درست، مدیران میتوانند بر انکیزه درونی افراد تاثیر مثبتی بگذارند. در مقابل مدیران وظیفه‌ای از قدیم عادت دارند که کارها را شکسته و به افراد زیردست جهت انجام در حد وظیفه بسپارند این کار در اسکرام به دلیل از بین بردن پایه‌های خودسازماندهی و زیرسوال بردن توانایی تیم در ایجاد ارزش، انرژی اعضای تیم را کاهش میدهد
-توسعه شایستگی
در اسکرام افراد تیم مدام گزارش به مدیران وظیفه‌ای ارائه می‌دهند که استاد و مالک نیستند. و مدیران با بازخورد مستمر خود به آنها در نقش مربیگری و دستیابی آنان به اهداف شغلی نقش فعالی دارند. مدیران محیطی ایجاد میکنند که افراد در آن مدام در حال یادگیری و افزایش مهارت هستند. مدیران خیلی شفاف باید بیان کنند که یادگیری مورد تشویق و از اولیت‌های افزاد و تیم و سازمان است. در سازمانها بازخورد معمولا بصورت سالیانه صورت میگیرد که این خلاف ذات اسکرام و بسیار مضر است، بازخورد باید در پایان هر حلقه یادگیری (پایان هر اسپرینت) یعنی زمانی که اعضا به آنها گزارش می‌دهند مناسب و هماهنگ باشد
#scrum
@code_crafters
👍3
-رهبری در حوزه وظیفه‌ای
مدیران وظیفه‌ای، رهبری حوزه عملکردی را برعهده دارند. انها به اعضا نمی‌گویند کار چگونه انجام دهند این منحر به تضعیف تیم خودسازمانده میشود. منتها کار اعضای خود را بازنگری کرده و در تدوین برنامه عملکردی آنها متفکر قضیه است. مدیران وظیفه‌ای خود افراد ماهر و با تجربه در حوزه وظیفه‌ای خودشان هستند. رهبری حوزه را برعهده گرفته تا اطمینان حاصل شود نتایج بارارزش و منسجمی خلق شوند. برای مثال مدیر تضمین کیفیت برای خودکارسازی آزمون‌ها به افراد حوزه خود که عضو تیم‌های اسکرام مختلفی هستند می‌خواهد که در انتخاب ابزار همکاری کنند
-حفظ یکپارچگی
تیم مبنای اصلی سنجش ارزش در چابکی است(تیم به عنوان واحد ظرفیت جایگزین افراد میشود) مدیران باید فعالانه در حفظ یکپارچگی تیم تلاش کنند (نباید افراد را در میانه اسپرینت برای انجام کاری از تیم خارج کنند یا بی‌جهت افراد را وادار بکار در چند تیم کنند) در پایان کار توسعه، مدیران باید کل تیم را یکجا به کار بعدی منتقل کنند
-همسو سازی و تطبیق محیط
برای دستیابی به مزایای اسکرام تمام زنحیره از تامین کننده‌ها تا مشتریان باید چابکی را بپذیرند و این کار با ترویج ارزش‌های چابکی، رفع موانع سازمانی، همسو کردن گروه‌های داخلی و شرکای تجاری انجام میشود
-ترویج ارزش‌های چابک
مدیران باید ارزش‌ها و اصول چابکی را بپذیرند. آنها را بفهمند و باور داشته باشند(پذیرش سختی‌ها و دشواری‌های آن)و دیگران را ترغیب به این کار کنند.
-رفع موانع سازمانی
مدیران باید پا به پای استاد برای رفع موانع سازمانی تلاش کنند. گاها برخی از موانع محیطی است و استاد بدون کمک مدیران نمی‌تواند آنها را رفع کند
-همسو کردن گروه‌های داخلی
اگر در سازمان بخشی اسکرام را پذیرفته و بخشی دیگر نپذیرفته باشد نمی‌توان از تمام مزایای اسکرام استفاده کرد و بهره برد. برای مثال واحد توسعه اسکرام را پذیرفته، اما واحد منابع انسانی نیرو با مهارت تی شکل استخدام نمی‌کند یا گروه استقرار بر پایه ارزش مستقر کردن بخش توسعه بر مبنای اسکرام پیش نمی‌رود. در این مواقع مدیران باید کل سازمان را در نظر داشته باشند و همه را با اصول چابک همسو کند
-همسو کردن شرکای تجاری
مدیران باید به سازمان کمک کنند تا رویکرد چابکتری را در حوزه مدیریت تامین کنندگان و برونسپاری در پیش بگیرد. اگر شیوه مشارکت به سبک سنتی باشد (قراردادهای سنگین و طولانی) نمی‌توان از پتانسیل اسکرام بهره برد. مدیران باید بیشتر از شیوه چابکی در روابط تجاری بهره ببرند. برای مثال بجای قرارداد تحویل و دریافت پروژه، تیم اسکرام از قبل آماده شده سازمان را اجاره کنند.
-مدیریت جریان خلق ارزش
در محیط اسکرامی مدیران مسئول تعیین مسیرهای استراتژیک و کسب اطمینان از تخصیص اقتصادی منابع سازمان برای رسیدن به اهداف استراتژیک هستند. جریان خلق ارزش با تکیه بر دیدگاه سیستمی، مدیریت امور اقتصادی، اندازه گیری و گزارش دهی مدیریت میشود
-اتخاذ دیدگاه سیستمی
جهت مدیریت موثر خلق ارزش، مدیران باید دیدگاه سیستمی داشته باشند.یک چالش اصلی عدم دیدگاه سیستمی مدیران است که علاقه دارند روی حوزه یا روی زمینه مورد علاقه خود تمرکز کنند که موجب میشود از تمام مزایای اسکرام بهره نگیرند، مدیران باید دیدگاه کل نگر داشته باشند
-مدیریت امور اقتصادی
از مدیران انتظار می‌رود در قبال منابع مالی امین و قابل اعتماد باشند.مدیران ارشد در اسکرام کماکان مسیولیت سود و زیان را برعهده دارند. مدیران وظیفه‌ای نیز در قبال چگونگی مصرف منابع مالی تحت اختیارشان مسئول هستند. از مدیران انتظار می‌رود بر امور اقتصادی در سطوح بالاتر سازمان نظارت کنند که در قالب مشارکت آنها در مدیریت سبد محصول و حاکمیت شرکتی نمود پیدا میکند.در هنگام مدیریت سبد محصول تعیین کنند که سرمایه گذاری روی کدام یک از فعالیت‌های توسعه و به چه مقدار انجام شود و ترتیبشان.مدیران مدام بازخوردهای آنی را مبتنی بر توسعه تکراری و تدریجی بازنگری میکنند و نسبت به آن عکس العمل نشان می‌دهند و اگر فعالیتی صرفه اقتصادی نداشته باشد آن را متوقف میکنند
-پایش معیارها و گزارش‌ها
گزارش‌های زیادی جهت بررسی به دست مدیران می‌رسد این فرصتیست که فقط معیارهایی که به جریان خلق ارزش کمک میکنند گرداوری و گزارش شوند.چند نمونه از این گزارش‌ها:
۱- تمرکز بر کارهای نیمه تمام تا افراد بیکار. اندازه گیری تعداد توقف جریان کار بجای موفقیت در مشغول نگه‌داشتن کارمندان.اگر زمان چرخه(زمان شروع و خاتمه کار)در حال افزایش باشد درباره دلایل ان تحقیق کنید
۲-اندازه گیری پیشرفت با دارایی‌هایی که کار میکنند و اعتبارسنجی شده‌اند اما چشم از تاثیرگذاری زمان و محدوده و بودجه و کیفیفت برندارید
۳-ایجاد سازوکاری جهت دریافت سریع بازخوردها.تعیین معیارهایی که موحب اندازه کیری سرعت تکمیل حلقه یادگیری باشد
#scrum
@code_crafters
👍2
مدیران پروژه
نقش مدیران پروژه چیست؟ آیا این نقش در سازمانهای اسکرامی وجود دارد؟
مسیولیت‌های مدیر پروژه در تیم اسکرام
استاد اسکرام با مدیر پروژه متفاوت است، کار هر دوی آنها رفع موانع است اما استاد در نقش خدمتگزار قرار دارد. وظایف ان بر اساس جدول تصویر اول در کامنت است. در صورت نبود مدیر پروژه وظایف آن مطابق جدول تصویر دوم در کامنت است
مدیر پروژه میتواند بر اساس میل و توانایی یکی از نقش‌های اسکرام را بگیرد، اگر انها بتوانند عادت فرماندهی و کنترل را کنار بگذارند استادان اسکرام ممتازی می‌شوند. همانطور که در جداول می‌بینید مالک بیشترین وظایف مدیریت پروژه را برعهده دارد اگر مدیر پروژه دانش کافی در دامنه مساله داشته باشد میتواند نقش مالک را بگیرد و بندرت اگر دانش فنی داشته باشد میتواند عضو تیم توسعه باشد
حفظ نقش مدیر پروژه
در سازمانهایی که بر روی محصولات بزرگ و لجستیکی کار میکنند حضور مدیر پروژه جهت ایحاد هماهنگی مفید است. هرچند که بهتر است تیم‌ها خود آن را انجام دهند چون حضور یکنفر برای اینکار موجب میشود که تیم از مسئولیت خود در این بخش سر باز بزند. در سازمانهای بزرگ با استفاده از اسکرام اسکرام‌ها هماهنگی صورت میگیرد و ارتباطات داخل خوشه توسط تیم انجام میشود اما مابین خوشه‌ای به درستی صورت نمیگیرد مدیر پروژه بعنوان یک خدمتگزار در اینجا مفید است و همچنین جهت ارتباط بین بخش اسکرامی و غیر اسکرامی سازمان، یا ارتباط با بخش بیرون از سازمان. جهت از حفظ مدیر پروژه نگه داشتن نقش او نیست بلکه کسب اطمینان از فهم درست وابستگی‌های موجود بین حوزه‌ها و شکل گیری ارتباط درست بین تیم‌هاست به گونه‌ای که هر تیم بتواند کارش را با سایر تیم‌ها به بهترین شکل ممکن هماهنگ کند. تصویر سوم در کامنت
#scrum
@code_crafters
نقش مدیران پروژه چیست؟ آیا این نقش در سازمانهای اسکرامی وجود دارد؟
مسیولیت‌های مدیر پروژه در تیم اسکرام
استاد اسکرام با مدیر پروژه متفاوت است، کار هر دوی آنها رفع موانع است اما استاد در نقش خدمتگزار قرار دارد. وظایف ان بر اساس جدول تصویر اول در کامنت است. در صورت نبود مدیر پروژه وظایف آن مطابق جدول تصویر دوم در کامنت است
مدیر پروژه میتواند بر اساس میل و توانایی یکی از نقش‌های اسکرام را بگیرد، اگر انها بتوانند عادت فرماندهی و کنترل را کنار بگذارند استادان اسکرام ممتازی می‌شوند. همانطور که در جداول می‌بینید مالک بیشترین وظایف مدیریت پروژه را برعهده دارد اگر مدیر پروژه دانش کافی در دامنه مساله داشته باشد میتواند نقش مالک را بگیرد و بندرت اگر دانش فنی داشته باشد میتواند عضو تیم توسعه باشد
حفظ نقش مدیر پروژه
در سازمانهایی که بر روی محصولات بزرگ و لجستیکی کار میکنند حضور مدیر پروژه جهت ایحاد هماهنگی مفید است. هرچند که بهتر است تیم‌ها خود آن را انجام دهند چون حضور یکنفر برای اینکار موجب میشود که تیم از مسئولیت خود در این بخش سر باز بزند. در سازمانهای بزرگ با استفاده از اسکرام اسکرام‌ها هماهنگی صورت میگیرد و ارتباطات داخل خوشه توسط تیم انجام میشود اما مابین خوشه‌ای به درستی صورت نمیگیرد مدیر پروژه بعنوان یک خدمتگزار در اینجا مفید است و همچنین جهت ارتباط بین بخش اسکرامی و غیر اسکرامی سازمان، یا ارتباط با بخش بیرون از سازمان. جهت از حفظ مدیر پروژه نگه داشتن نقش او نیست بلکه کسب اطمینان از فهم درست وابستگی‌های موجود بین حوزه‌ها و شکل گیری ارتباط درست بین تیم‌هاست به گونه‌ای که هر تیم بتواند کارش را با سایر تیم‌ها به بهترین شکل ممکن هماهنگ کند. تصویر سوم در کامنت
#scrum
@code_crafters
👍2❤1
اصول برنامه ریزی اسکرام
در اسکرام برنامه ریزی در سطوح مختلفی از جزییات و در مقاطع زمانی متعددی انجام میشود. بخش عمده برنامه ریزی بجای زودهنگام و در ابتدا، بموقع و در زمان مناسب انجام میشود.
بیایید یکبار آنچه را که قبلا درباره برنامه ریزی خواندیم مرور کنیم و در بخش‌های بعدی به تشریح بهتر از برنامه ریزی های سبد محصول، محصول و انتشار بپردازیم
نگاه کلی
انچه قبلا راجب اصول کلیدی اسکرام گفته شد
۱-نمی‌توان در ابتدا طرح‌هایی درست و کامل تهیه کرد
۲- برنامه ریزی زودهنگام اگر بدون افراط باشد میتواند مفید باشد
۳- انتخاب‌های برنامه ریزی را تا اخرین لحظه مسئولیت پذیری باز نگهدارید
۴- به تطبیق و برنامه‌ریزی مجدد بیش از پای‌بندی به طرح توجه کنید
۵- موجودی برنامه‌ریزی را درست مدیریت کنی
۶-طرفدار انتشارات زود به زود و کوچکتر باشید
#scrum
@code_crafters
در اسکرام برنامه ریزی در سطوح مختلفی از جزییات و در مقاطع زمانی متعددی انجام میشود. بخش عمده برنامه ریزی بجای زودهنگام و در ابتدا، بموقع و در زمان مناسب انجام میشود.
بیایید یکبار آنچه را که قبلا درباره برنامه ریزی خواندیم مرور کنیم و در بخش‌های بعدی به تشریح بهتر از برنامه ریزی های سبد محصول، محصول و انتشار بپردازیم
نگاه کلی
انچه قبلا راجب اصول کلیدی اسکرام گفته شد
۱-نمی‌توان در ابتدا طرح‌هایی درست و کامل تهیه کرد
در رویکرد سنتی برای تولید محصول یک طرح تفصیلی با این عنوان که پوششی جامع برآنچه لازم است صورت میگیردد بدون چنین طرحی نمی‌دانیم قرار است بکجا رسیده و نمیتوانیم افراد را در گروه‌های چند تیمی هماهنگ کنیم، این درست است. در اسکرام معتقدیم که نمی‌توان در ابتدا همه‌ی کارها را به درستی انجام داد. به همین خاطر سعی نمی‌کنیم همه فرآورده‌ها را در ابتدا و زودهنگام تهیه کنیم. اما جهت ایجاد تعادل بین برنامه ریزی زودهنگام و به‌موقع، بخشی از فرآورده‌های برنامه ریزی را در ابتدا تولید میکنیم
۲- برنامه ریزی زودهنگام اگر بدون افراط باشد میتواند مفید باشد
هیچگاه نمی‌توانید یک طرح تفصیلی کامل و با جزییات برای محصول بنویسید. اینکار جز اتلاف وقت و ضرف هزینه نیست. در طی اجرای پروژه شما با حالت‌ها و اتفاقات غیرقابل پیش بینی روبرو هستید که باید سریع خود را با آن تطبیق دهید. شما باید بین پیش بینی زودهنگام و تطبیق بموقع تعادل برقرار کنید
۳- انتخاب‌های برنامه ریزی را تا اخرین لحظه مسئولیت پذیری باز نگهدارید
از این اصل برای برنامه ریزی زودهنگام و برنامه ریزی بموقع استفاده کنید. توقف برنامه ریزی بر اساس رویکرد به‌موقع تا زمانیکه اطلاعات کامل‌تری در اختیار داشته باشیم و آن را در بهترین شکل انجام دهیم
۴- به تطبیق و برنامه‌ریزی مجدد بیش از پای‌بندی به طرح توجه کنید
تایید بیش از حد بر طرح اولیه و توجه ناکافی به برنامه ریزی مستمر، یکی از مسائل رایج در توسعه محصول است. اگر زمان زیادی را در ابتدا جهت ایجاد طرح اولیه جامع صرف کنیم، در هنگام نیاز به تغییر، کمتر انعطاف پذیر بوده و سعی در اجرای طرح خود میکنیم. در حالیکه اگر به باور اسکرام در ابتدا نمی‌توان یک طرح جامع را برنامه ریزی کرد و در صورت نیاز به تغییرات و برنامه ریزی مجدد نسبت به طرح اولیه ارزش بیشتری قائل میشویم. اعتقاد بیش از به طرح اولیه در هنگامیکه پروژه انحراف میشود موجب میشود تا کمتر به اشتباه بودن طرح مشکوک شویم. هرچند در اسکرام به برنامه ریزی اولیه معتقدیم اما اگر بدانید در هنگام تدوین طرح‌های زودهنگام، اطلاعات کمی درباره محصول وجود دارد، آنگاه چنین باوری خردمندانه است. طرح زودهنگام، جهالت و بی دانشی ما در ابتدای کار را با ظرافت خاصی پنهان میکند. در اسکرام همانگونه که فرضیات را زود به زود اعتبارسنجی میکنیم، برنامه ریزی را هم زود به زود انجام می‌دهیم. از یادگیری معتبر برای تهیه طرح‌های بهتر و مفیدتر استفاده میکنیم. اگر اشکالی در طرح وجود داشته باشد نگران نیستیم چون می‌دانیم بزودی آن را با طرح دقیقتری جایگزین خواهیم کرد. و چون از اسپرینت‌های کوتاه استفاده میکنیم اگر اشتباهی در طرح باشد نیز می‌دانیم که زمان زیادی را هدر نداده‌ایم. در اسکرام برنامه ریزی را در چند سطح از جزییات انجام می‌دهیم
۵- موجودی برنامه‌ریزی را درست مدیریت کنی
در پست‌های قبلی به موضوع مهمی با عنوان مدیریت کار در جریان اشاره کردیم. باید باور داشته باشیم هنگام اسجاد تعادل بین برنامه ریزی ژودهنگام و برنامه ریزی بموق، تولید انبوهی از مستندات در برنامه ریزی پیش‌بینانه اعتبارسنجی نشده کار بیهوده‌ای است. به یک نمودار گانت بزرگ توجه کنید که در طول توسعه محصول و ارزیابی فرضیات اولیه با کسب دانش جدید از سوی دیگر به این نتیجه میرسیم که طرح اولیه اشتباه بوده است. و اکنون باید بپذیریم طرح دور ریخته و اتلاف ناشی از دور ریختن و تهیه طرح جدید را بپذیریم. اینکار سه نوع اتلاف ایجاد میکند:
۱- کار بیهوده‌ای که صرف تهیه طرحی شده است که حالا باید دور ریختن شود
۲- کار قابل توجهی که احتمالا صرف به روزرسانی طرح شده است
۳-فرصت‌هایی که می‌توانست صرف فعالیت‌های ارزشمندتری شود
یا توجه به وجود چنین ریسک‌های در ارائه طرحی برای آینده خیلی دور تنها دلیل ما پاسخ به سوالاتی از قبیل زمان تحویل پروژه و تعداد نیروهای مورد نیاز است
۶-طرفدار انتشارات زود به زود و کوچکتر باشید
اسکرام طرفدار انتشارات کوچکتر و زود به زود است زیرا این شیوه باعث میشود بازخوردها سریعتر دریافت شده و بازگشت سرمایه محصول نیز بهبود یابد
#scrum
@code_crafters
👍4
۷- با هدف یادگیری سریع، برنامه ریزی کنید و در صورت لزوم مسیر را تغییر دهید
#scrum
@code_crafters
کاری انجام دهیم، سریع یادمیگیریم، درصورت نیاز تغییر مسیر می‌دهیم، هیچ پیش بنی زودهنگامی نمی‌تواند جایگزین این رویکرد شود. منظور ما نسبت به تغییر مسیر واقع‌نگر بودن نسبت به اموخته‌هایمان است جهت تغییر مسیر دادن. تعریف تغییر مسیر: اصلاح ساخت‌یافته‌ی مسیر حرکت به منظور سنجش فرضیات بنیادی جدید درباره محصول، استراتژی و موتور رشد و توسعه
هدف ما حرکت سریع و اقتصادی در حلقه یادگیری است. پس بنابراین طرح‌ها باید بگونه‌ای سازماندهی شوند که یادگیری یکی از اهداف اصلی باشد. با دریافت سریع بازخورد میتوان تعیین کرد که آیا طرح‌ها ما را در مسیر درست رشد و ترقی پیش میبرند یا خیر
#scrum
@code_crafters
👍3
برنامه ریزی چندسطحی
اسکرام برنامه ریزی را در چندسطح مختلف از کلان به جزئ انجام میدهد و این کار را بازه‌های زمانی متعددی انجام میدهد. ابتدا نگاه کلی به آن انداخته و در بخش‌های بعدی هرکدام را با جزییات بررسی میکنیم
نگاه کلی
بالاترین سطح برنامه ریزی استراتژیک هست که نقش مهمی در موفقیت سازمان دارد. اسکرام بطور رسمی فقط برنامه ریزی اسپرینت و روزانه دارد اما در کنارش برنامه ریزی سبد محصول، محصول و انتشار را نیز بررسی میکنیم تصویر اول در کامنت
در این تصویر پنج سطح مختلف از برنامه ریزی میبینیم که شامل افق برنامه ریزی، شرکت‌کنندگان، نقطه تمرکز، اقلام قابل تحویل می باشد برای مثال یک جدول برنامه ریزی برای وبسایت رسمی اسکرام که هدف آن ترویج اسمرام بود را در تصویر دوم در کامنت می‌بینید
برنامه‌ریزی سبد محصول
برنامه ریزی سبد محصول یا مدیریت سبد محصول فعالیتی است که طی آن تعیین میکنیم روی چه محصولاتی، با چه ترتیبی و چه مدت باید کار کنیم. برنامه ریزی سبد محصول کلانتر از محصول است در برنامه ریزی سبد محصول با مجموعه‌ای از محصولات سروکار داریم. یکی از ورودی‌های آن ایده محصولی است که چشم انداز آن به تازگی در برنامه‌ریزی محصول تدوین شده است.
برنامه ریزی محصول (ترسیم چشم انداز)
هدف از آن فهمیدن ماهیت محصول بالقوه و تهیه برنامه‌ای کلی برای ساخت آن است. که با تدوین چشم انداز آغاز و با تهیه بک‌لاگ کلانی از محصول و در اغلب موارد نقشه راه محصول ادامه پیدا میکند
در پایان برنامه ریزی محصول باید سه مقدار زیر وجود داشته باشد:
- چشم انداز محصول
- بک‌لاگ محصول به همراه داستان‌های کاربر برآورده شده
- نقشه راه محصول
برنامه ریزی انتشار
هدف از آن ایجاد توازن بین محدوده، تاریخ انتشار و بودجه در تحویل تدریجی محصول است. که این برنامه ریزی بعد از ترسیم چشم انداز و قبل از شروع اولین اسپرینت هر انتشار انجام شود. یکی از راه‌های ساده کشیدن خط بر روی بک لاگ هستش که انتشارها رو از هم جدا کرد. هر انتشار باید بعد زمان داشته باشد که با اسپرینت نمایش می‌دهیم هر انتشار ممکن است در چند اسپرینت تمام شود. تصویر سوم در کامنت
برنامه‌ریزی اسپرینت
در ابتدای هر اسپرینت انجام میشود و طی آن در مورد اقلامی از بک‌لاگ محصول که در اسپرینت انجام خواهد شد توافق میشود. یکی از خروجی‌های آن بک‌لاگ اسپرینت است. تیم در برنامه ریزی اسپرینت، سطح بعدی از برنامه ریزی تفصیلی را بر اساس رویکرد «به‌موقع» انجام میدهد
برنامه‌ریزی روزانه
جزیی‌ترین سطح برنامه‌ریزی تیم در جلسات روزانه اسکرام است که هر نفر موارد زیر را توضیح میدهد:
- از جلسه روز قبل تا کنون چکاری انجام داده است
- چکارهایی را برای امروز برنامه ریزی کرده است
- با چه مشکلات و موانعی روبه‌رو است
این موحب میشود که تیم برای برنامه ریزی روی منابع آماده شود. برای مثال یکنفر میگوید امروز تا ظهر روی رویه دیتابیس کار میکند و اتمام میشود این موجب میشود نفر دیگر مطلع شود که از بعدازظهر میتواند روی منطق تجاری کار کند. تصویر چهارم در کامنت
در بخش‌های بعدی هر سطح از برنامه ریزی را با جزئیات بیشتر و جداگانه بررسی خواهیم کرد
#scrum
@code_crafters
اسکرام برنامه ریزی را در چندسطح مختلف از کلان به جزئ انجام میدهد و این کار را بازه‌های زمانی متعددی انجام میدهد. ابتدا نگاه کلی به آن انداخته و در بخش‌های بعدی هرکدام را با جزییات بررسی میکنیم
نگاه کلی
بالاترین سطح برنامه ریزی استراتژیک هست که نقش مهمی در موفقیت سازمان دارد. اسکرام بطور رسمی فقط برنامه ریزی اسپرینت و روزانه دارد اما در کنارش برنامه ریزی سبد محصول، محصول و انتشار را نیز بررسی میکنیم تصویر اول در کامنت
در این تصویر پنج سطح مختلف از برنامه ریزی میبینیم که شامل افق برنامه ریزی، شرکت‌کنندگان، نقطه تمرکز، اقلام قابل تحویل می باشد برای مثال یک جدول برنامه ریزی برای وبسایت رسمی اسکرام که هدف آن ترویج اسمرام بود را در تصویر دوم در کامنت می‌بینید
برنامه‌ریزی سبد محصول
برنامه ریزی سبد محصول یا مدیریت سبد محصول فعالیتی است که طی آن تعیین میکنیم روی چه محصولاتی، با چه ترتیبی و چه مدت باید کار کنیم. برنامه ریزی سبد محصول کلانتر از محصول است در برنامه ریزی سبد محصول با مجموعه‌ای از محصولات سروکار داریم. یکی از ورودی‌های آن ایده محصولی است که چشم انداز آن به تازگی در برنامه‌ریزی محصول تدوین شده است.
برنامه ریزی محصول (ترسیم چشم انداز)
هدف از آن فهمیدن ماهیت محصول بالقوه و تهیه برنامه‌ای کلی برای ساخت آن است. که با تدوین چشم انداز آغاز و با تهیه بک‌لاگ کلانی از محصول و در اغلب موارد نقشه راه محصول ادامه پیدا میکند
چشم انداز:
توصیفی شفاف از حوزه‌هایی است که برای ذینفعان با ارزش است
بک‌لاگ کلان محصول:
بعد از توصیف چشم انداز نوبت به ایجاد بک لاگ کلان محصول می‌رسد که شامل اپیک‌ها می‌باشد. برای مثال در ساخت وبسایت اسکرام شامل موارد زیر میشود:
- بعنوان مربی اسکرام میخواهم زمان و مکان برگذاری دوره‌ها را در وبسایت اعلام کنم تا به اطلاع عموم برسد
- به عنوان یک دانشجو میخواهم اطلاعات همه دوره‌های عمومی اسکرام را ببینم تا کلاسی را پیدا کنم که با شرایطم مطالقت داشته باشد
اگر محصول از قبل وجود داشته باشد برخی اقلام بک‌لاگ مشخص است در غیر این صورت باید بخشی از نیازمندی‌ها را کمینه کنیم
نقشه راه:
سپس نوبت به تهیه نقشه راه یا همان نقشه راه انتشار میرسیم که بیانگر ماهیت تدریجی ساخت و تحویل در طول زمان و عوامل مهم و تاثیرگذار در هر یک از انتشارها است. امروزه بسیاری از سازمانها رویکرد استقرار پیوسته دارند یعنی به محض آماده شدن یک ویژگی آن را استقرار می‌دهند در این نوع نیازی به ترسیم نقشه راه نیست. اما ابزار مناسبی برای سازمان در موارد زیر است:
- بررسی و انتخاب مجموعه بزرگتری از ویژگی‌ها
- شناسایی قیدها و محدودیت‌هایی که باعث می‌شوند برخی از ویژگی‌ها بصورت همزمان توسعه یابند
- تعیین زمان مناسب برای انتشار ویژگی‌ها
در پایان برنامه ریزی محصول باید سه مقدار زیر وجود داشته باشد:
- چشم انداز محصول
- بک‌لاگ محصول به همراه داستان‌های کاربر برآورده شده
- نقشه راه محصول
برنامه ریزی انتشار
هدف از آن ایجاد توازن بین محدوده، تاریخ انتشار و بودجه در تحویل تدریجی محصول است. که این برنامه ریزی بعد از ترسیم چشم انداز و قبل از شروع اولین اسپرینت هر انتشار انجام شود. یکی از راه‌های ساده کشیدن خط بر روی بک لاگ هستش که انتشارها رو از هم جدا کرد. هر انتشار باید بعد زمان داشته باشد که با اسپرینت نمایش می‌دهیم هر انتشار ممکن است در چند اسپرینت تمام شود. تصویر سوم در کامنت
برنامه‌ریزی اسپرینت
در ابتدای هر اسپرینت انجام میشود و طی آن در مورد اقلامی از بک‌لاگ محصول که در اسپرینت انجام خواهد شد توافق میشود. یکی از خروجی‌های آن بک‌لاگ اسپرینت است. تیم در برنامه ریزی اسپرینت، سطح بعدی از برنامه ریزی تفصیلی را بر اساس رویکرد «به‌موقع» انجام میدهد
برنامه‌ریزی روزانه
جزیی‌ترین سطح برنامه‌ریزی تیم در جلسات روزانه اسکرام است که هر نفر موارد زیر را توضیح میدهد:
- از جلسه روز قبل تا کنون چکاری انجام داده است
- چکارهایی را برای امروز برنامه ریزی کرده است
- با چه مشکلات و موانعی روبه‌رو است
این موحب میشود که تیم برای برنامه ریزی روی منابع آماده شود. برای مثال یکنفر میگوید امروز تا ظهر روی رویه دیتابیس کار میکند و اتمام میشود این موجب میشود نفر دیگر مطلع شود که از بعدازظهر میتواند روی منطق تجاری کار کند. تصویر چهارم در کامنت
#scrum
@code_crafters
👍4
برنامه ریزی سبد محصول
بسیاری از سازمانها بر روی تولید چند محصول همزمان کار میکنند که نیازمند رویکردی هستند تا تجربه خود را با چابکی ادغام کنند در غیر این صورت شکاف عمیقی بین برنامه ریزی و مدیریت سبد محصول بوجود می‌آید. در این بخش ۱۱ استراتژی مورد استفاده را در قالب ۳ گروه زمانبندی، جریان ورودی محصول و جریان خروجی محصول توضیح داده و روشی جهت تصمیم‌گیری بابت ادامه یا توقف سرمایه گذاری روی محصولات را بررسی خواهیم کرد
نگاه کلی
برنامه ریزی سبد محصول فعالیتی است که طی آن مشخص میشود روی چه اقلامی از بک‌لاگ به چه ترتیبی و چه مدتی کار انجام شود. یک قلم از سبد میتواند یک محصول، بخش قابل عرضه از یک محصول یا یک پروژه باشد
زمان انجام
برنامه ریزی سبد محصول فعالیتی است که هیچگاه به پایان نمی‌رسد و تا زمانیکه بیش از یک محصول داریم این روند. برنامه ریزی سبد کلانتر از برنامه ریزی محصول است اما به معنای تقدم بر آن نیست. ترسیم چشم انداز محصول میتواند ورودی خوبی برای برنامه ریزی سبد باشد. ابتدا بر روی سرمایه گذاری روی محصول و بعدا در کجا قرار گرفتن محصول در بک لاگ تصمیم گرفته میشود. برنامه ریزی سبد فقط برای محصولات جدید نیست بلکه در بازه‌های زمانی منظم و برنامه ریزی شده برای بازنگری محصولات جاری (در حال توسعه، عملیاتی شده، در حال فروش) نیز انجام میشود
شرکت کنندگان
از آنجا که برنامه ریزی سبد هم با محصولات جدید و جاری در ارتباط است لازم است مالکان به‌همراه ذینفعان داخلی، معماران ارشد و مدیران فنی در آن شرکت داشته باشند. بهتر است ذینفعان درک درستی از کسب و کار داشته باشند تا در اولویت بندی بک‌لاگ خوب عمل کنند در برخی سازمانها گروهی با عنوان هیئت نظارت بر این فرآیند نظارت میکنند. مالکان در برنامه ریزی سبد به‌عنوان نماینده محصول خود شرکت کرده تا منابع مورد نیاز خود را اعلام کرده و از آن دفاع کنند. جهت اطمینان از قید فنی مهم در تصمیم گیری‌ها معماران ارشد یا مدیران فنی حضور دارند
فرآیند
برنامه ریزی سبد شامل محصولات جاری و محصولاتیست که چشم انداز آنها به تازگی ترسیم شده است. محصولات جدید به همراه داده‌هایی مانند هزینه، مدت تولید، ارزش و ریسک به برنامه ریزی سبد وارد می‌شوند که موارد در مرحله ترسیم چشم انداز محصول بدست می‌آیند. محصولات جاری نیز به همراه بازخورد مشتریان میانی، بهای تمام شده، زمان بندی، محدوده برآورد شده محصول، میزان بدهی فنی و اطلاعات بازار وارد برنامه ریزی سبد محصول می‌شوند که در تعیین مسیر آینده محصولات تاثیر گذارند. تصویر اول در کامنت
فعالیت برنامه ریزی سبد دو خروجی دارد
۱- بک‌لاگ سبد محصول که فهرست اولویت بندی شده از محصولات آتی است که تایید شده اما توسعه آنها هنوز شروع نشده
۲- مجموعه‌ای از محصولات فعال است که دو دسته هستند، دسته اول محصولات جدید تایید شده که در انتظار شروع توسعه هستند، دسته دوم محصولاتی که در لیست محصولات جاری قرار گرفته و ادامه سرمایه گذاری آنها تایید شده است
برای رسیدن به این خروجی‌ها چهار فعالیت انجام میشود: زمان بندی، مدیریت جریان ورودی، مدیریت جریان خروجی، و مدیریت محصولات جاری. تصویر دوم در کامنت
استراتژی زمان بندی
باید منابع سازمان را به شیون اقتصادی به محصولات اختصاص داد. روش‌ها و استراتژی‌های گوناگونی جهت قرار دادن محصولات در سبد وجود دارد از جمله:
۱- بهینه کردن سود چرخه‌ی عمر
۲- محاسبه هزینه تاخیر
۳- برآورد صحیح، نه دقیق
بهینه کردن سود چرخه‌ی عمر
ابتدا باید تصمیم بگیریم از چه متغیری برای اندازه گرفتن بهینه سازی استفاده کنیم. چارچوب اقتصادی یکی از موارد پیشنهادی است که میتوان سود چرخه‌ی عمر را بررسی کرد که بر اساس آن باید سود چرخه‌ی عمر کل سبد بیشینه باشد. سود چرخه عمر، سودیست که یک محصول برای همیشه دارد لذا در سبد این را برای کل محصولات در نظر می‌گیریم و سود برخی محصولات را کاهش می‌دهیم بنابراین استراتژی سود چرخه عمر یافتن نگترتیب قرار دادن اقلام در بک‌لاگ سبد است که موجب بیشترین سود شود. در تعیین سود چرخه عمر دو عامل هزینه‌ی تاخیر و مدت تولید دارای اهمیت می‌باشد (مدت تولید محصول شاخص جایگزین حجم کار و اندازه‌ی محصول است) براساس مشاهده این دو مورد در محصولات سه گزینه پیش روی ما است (تصویر سوم در کامنت)
#scrum
@code_crafters
بسیاری از سازمانها بر روی تولید چند محصول همزمان کار میکنند که نیازمند رویکردی هستند تا تجربه خود را با چابکی ادغام کنند در غیر این صورت شکاف عمیقی بین برنامه ریزی و مدیریت سبد محصول بوجود می‌آید. در این بخش ۱۱ استراتژی مورد استفاده را در قالب ۳ گروه زمانبندی، جریان ورودی محصول و جریان خروجی محصول توضیح داده و روشی جهت تصمیم‌گیری بابت ادامه یا توقف سرمایه گذاری روی محصولات را بررسی خواهیم کرد
نگاه کلی
برنامه ریزی سبد محصول فعالیتی است که طی آن مشخص میشود روی چه اقلامی از بک‌لاگ به چه ترتیبی و چه مدتی کار انجام شود. یک قلم از سبد میتواند یک محصول، بخش قابل عرضه از یک محصول یا یک پروژه باشد
زمان انجام
برنامه ریزی سبد محصول فعالیتی است که هیچگاه به پایان نمی‌رسد و تا زمانیکه بیش از یک محصول داریم این روند. برنامه ریزی سبد کلانتر از برنامه ریزی محصول است اما به معنای تقدم بر آن نیست. ترسیم چشم انداز محصول میتواند ورودی خوبی برای برنامه ریزی سبد باشد. ابتدا بر روی سرمایه گذاری روی محصول و بعدا در کجا قرار گرفتن محصول در بک لاگ تصمیم گرفته میشود. برنامه ریزی سبد فقط برای محصولات جدید نیست بلکه در بازه‌های زمانی منظم و برنامه ریزی شده برای بازنگری محصولات جاری (در حال توسعه، عملیاتی شده، در حال فروش) نیز انجام میشود
شرکت کنندگان
از آنجا که برنامه ریزی سبد هم با محصولات جدید و جاری در ارتباط است لازم است مالکان به‌همراه ذینفعان داخلی، معماران ارشد و مدیران فنی در آن شرکت داشته باشند. بهتر است ذینفعان درک درستی از کسب و کار داشته باشند تا در اولویت بندی بک‌لاگ خوب عمل کنند در برخی سازمانها گروهی با عنوان هیئت نظارت بر این فرآیند نظارت میکنند. مالکان در برنامه ریزی سبد به‌عنوان نماینده محصول خود شرکت کرده تا منابع مورد نیاز خود را اعلام کرده و از آن دفاع کنند. جهت اطمینان از قید فنی مهم در تصمیم گیری‌ها معماران ارشد یا مدیران فنی حضور دارند
فرآیند
برنامه ریزی سبد شامل محصولات جاری و محصولاتیست که چشم انداز آنها به تازگی ترسیم شده است. محصولات جدید به همراه داده‌هایی مانند هزینه، مدت تولید، ارزش و ریسک به برنامه ریزی سبد وارد می‌شوند که موارد در مرحله ترسیم چشم انداز محصول بدست می‌آیند. محصولات جاری نیز به همراه بازخورد مشتریان میانی، بهای تمام شده، زمان بندی، محدوده برآورد شده محصول، میزان بدهی فنی و اطلاعات بازار وارد برنامه ریزی سبد محصول می‌شوند که در تعیین مسیر آینده محصولات تاثیر گذارند. تصویر اول در کامنت
فعالیت برنامه ریزی سبد دو خروجی دارد
۱- بک‌لاگ سبد محصول که فهرست اولویت بندی شده از محصولات آتی است که تایید شده اما توسعه آنها هنوز شروع نشده
۲- مجموعه‌ای از محصولات فعال است که دو دسته هستند، دسته اول محصولات جدید تایید شده که در انتظار شروع توسعه هستند، دسته دوم محصولاتی که در لیست محصولات جاری قرار گرفته و ادامه سرمایه گذاری آنها تایید شده است
برای رسیدن به این خروجی‌ها چهار فعالیت انجام میشود: زمان بندی، مدیریت جریان ورودی، مدیریت جریان خروجی، و مدیریت محصولات جاری. تصویر دوم در کامنت
استراتژی زمان بندی: کمک میکند تا ترتیب قرار گرفتن محصولات در بک‌لاگ سبد محصول تعیین شوند
استراتژی جریان ورودی: به شرکت کنندگان کمک میکند تا بدانند چه زمانی اقلام را به یک لاگ سبد اضافه کنند
استراتژی جریان خروجی: زمان خروج یک محصول از سبد را مشخص میکند
استراتژی محصولات جاری: تصمیم گیری درباره حفظ، تغییر مسیر، تحویل یا کنار گذاشتن محصولات جاری استفاده میشود
استراتژی زمان بندی
باید منابع سازمان را به شیون اقتصادی به محصولات اختصاص داد. روش‌ها و استراتژی‌های گوناگونی جهت قرار دادن محصولات در سبد وجود دارد از جمله:
۱- بهینه کردن سود چرخه‌ی عمر
۲- محاسبه هزینه تاخیر
۳- برآورد صحیح، نه دقیق
بهینه کردن سود چرخه‌ی عمر
ابتدا باید تصمیم بگیریم از چه متغیری برای اندازه گرفتن بهینه سازی استفاده کنیم. چارچوب اقتصادی یکی از موارد پیشنهادی است که میتوان سود چرخه‌ی عمر را بررسی کرد که بر اساس آن باید سود چرخه‌ی عمر کل سبد بیشینه باشد. سود چرخه عمر، سودیست که یک محصول برای همیشه دارد لذا در سبد این را برای کل محصولات در نظر می‌گیریم و سود برخی محصولات را کاهش می‌دهیم بنابراین استراتژی سود چرخه عمر یافتن نگترتیب قرار دادن اقلام در بک‌لاگ سبد است که موجب بیشترین سود شود. در تعیین سود چرخه عمر دو عامل هزینه‌ی تاخیر و مدت تولید دارای اهمیت می‌باشد (مدت تولید محصول شاخص جایگزین حجم کار و اندازه‌ی محصول است) براساس مشاهده این دو مورد در محصولات سه گزینه پیش روی ما است (تصویر سوم در کامنت)
#scrum
@code_crafters
👍4
محاسبه هزینه تاخیر
در مرتب سازی محصولات در سبد باید توجه داشت که تمامی محصولات باهم شروع نمی‌شوند و تاخیر در شروع به معنای تاخیر در تحویل است و این یعنی صرف هزینه کردن که مبلغ آن قابل محاسبه است. هزینه تاخیر موجب تصمیم گیری آگاهانه میشود و با این وجود سازمانها عاجز از پاسخ دادن به این سوال هستند که اگر یک محصول یکماه تاخیر داشته باشد چقدر هزینه بردار است؟
اکثر سازمانها در این شرایط کار بر روی محصول با بازدهی بیشتر را شروع میکنند که تفکری خوب اما اشتباه است، با یک مثال پیش برویم دو محصول داریم که اولی هزینه بازگشتی بیشتری نسبت به دومی دارد، در این حالت میگوییم که خب ابتدا توسعه اولی را آغاز کنیم. اما اگر هزینه تاخیر اولی ۵ هزار واحد و دومی ۷۵ هزار واحد باشد آنگاه متوجه میشوید که محاسبه هزینه تاخیر تاثیر بسیار زیادی در رویکرد سازمان و ترتیب اقلام خواهد داشت. هزینه تاخیر نشانگر این است که زمان بشدت روی متغیرهای ما تاثیر گذار است. در مثال ما متغیرهای تحت تاثیر زمان عبارت‌اند از:
۱- زمان شروع و پایان توسعه
۲- میزان منابع در دسترس در زمان توسعه
۳- هزینه منابع
۳- مبلغی که افراد حاضر به پرداخت آن برای محصول هستند
۴- ریسک‌های موجود
۵- احتمال وقوع این ریسک‌ها و میزان تاثیر آنها بر هزینه
تاخیر و تسریع در شروع توسعه و مقادیر بالا بر سود محصول تاثیرگذار است بنابراین هزینه تاخیر تنها عامل تعیین کننده اولویت دهی اقلام سید نیست و باید زمان را که تاثیری بر مقادیر هزینه، سود، دانش و ریسک را دارد نیز در نظر گرفت.
یکی از راه‌های محاسبه هزینه تاخیر برابر با جمع سه عامل زیر است:
۱- ارزش کاربری: ارزش بالقوه از نگاه کاربر
۲- ارزش زمانی: چگونگی کاهش «ارزش کاربری» با گذشت زمان
۳- ارزش ناشی از کاهش ریسک یا استفاده از فرصت
به هر یک از این گزینه‌ها عددی مابین ۱ تا ۱۰ داده شده و جمع نهایی این سه برابر با جمع هزینه تاخیر است که میتوان با آن پروفایل هزینه تاخیر را بررسی کرد. تصویر اول در کامنت
هزینه تاخیر عامل بسیار مهمی در اولویت بندی اقتصادی سبد بازسازی محصولات است
برآورد صحیح، نه دقیق
برای زمان بندی درست اقلام در بک لاگ سبد باید نسبت حجم کار به هزینه هر محصول را بدانیم. در ابتدای برآورد اطلاعات کمی در اختیار داریم لذا در برآورد هر قلم بدنبال صحت هستیم، نه دقت
در بخش‌های قبلی گفتیم سازمانها برای برآورد اقلام بجای اعداد از سایز استفاده میکنند (تصویر دوم در کامنت) که معادل هزینه محصول هستند که شامل حقوق و دستمزد کارکنان، مخارج سرمایه‌ای و سایر هزینه‌های تولید محصول است که معمولا بیشترین هزینه مربوط به حقوق است. مزیت رویکرد استفاده از سایز به اندازه مافی دقیق بودن آن است و اطلاعات مفیدی برای تصمیم گیری در سطح سبد محصول فراهم میکند
استراتژی‌های جریان ورودی
ترسیم چشم انداز به ما اطلاعات مفید و مورد نیاز برای تصمیم گیری اقتصادی در مورد ادامه یا توقف محصول فراهم میکند. و استراتژی جریان ورودی به ما در نحوه چگونگی اعمال فیلتر اقتصادی برای توقف یا ادامه محصول را میدهد و به موارد زیر نیز می‌پردازد
۱- اعمال فیلتر اقتصادی
خروجی ترسیم چشم انداز، عبارت است از سند چشم‌انداز محصول و اطلاعات لازم برای شفاف سازی.
این خروجی شامل داده‌های مربوط به محصول جدید است که بعنوان ورودی برنامه ریزی استفاده میشود که سازمان بر اساس آن تصمیم به ادامه یا توقف محصول را میگیرد.
هر سازمان فیلترهای اقتصادی مخصوص بخود را دارد اما یک فیلتر خوب باید فرصت‌هایی که نسبت ارزش به هزینه آنها چشم گیر است را به سرعت تایید کند و هرچیزی غیر از این را رد کند مگر در شرایط خاص (اگر ارزش محصول هزینه را پوشش میدهد آن را در سبد محصول قرار دهید، اگر بحث مبلغ ناچیز است آن را رد کنید)
۲- ایجاد توازن بین نرخ ورود و نرخ خروج
در عمل انتظار داریم یک جریان پیوسته در ورود اقلام به سبد و خروج آن برقرار باشد و از طرفی هم نمی‌خواهیم افزودن یکباره تعداد زیادی از محصولات، بک لاگ محصولات را شلوغ کنیم، چنین کاری فشار قابل توجهی به سیستم وارد میکند. اکثر سازمانها تصمیمات اقتصادی خود را در سه ماهه سوم سال با یک رویداد برگزار میکنند و محصولات زیادی را در سبد قرار می‌دهند که منجر به اختلال میشود
#scrum
@code_crafters
در مرتب سازی محصولات در سبد باید توجه داشت که تمامی محصولات باهم شروع نمی‌شوند و تاخیر در شروع به معنای تاخیر در تحویل است و این یعنی صرف هزینه کردن که مبلغ آن قابل محاسبه است. هزینه تاخیر موجب تصمیم گیری آگاهانه میشود و با این وجود سازمانها عاجز از پاسخ دادن به این سوال هستند که اگر یک محصول یکماه تاخیر داشته باشد چقدر هزینه بردار است؟
اکثر سازمانها در این شرایط کار بر روی محصول با بازدهی بیشتر را شروع میکنند که تفکری خوب اما اشتباه است، با یک مثال پیش برویم دو محصول داریم که اولی هزینه بازگشتی بیشتری نسبت به دومی دارد، در این حالت میگوییم که خب ابتدا توسعه اولی را آغاز کنیم. اما اگر هزینه تاخیر اولی ۵ هزار واحد و دومی ۷۵ هزار واحد باشد آنگاه متوجه میشوید که محاسبه هزینه تاخیر تاثیر بسیار زیادی در رویکرد سازمان و ترتیب اقلام خواهد داشت. هزینه تاخیر نشانگر این است که زمان بشدت روی متغیرهای ما تاثیر گذار است. در مثال ما متغیرهای تحت تاثیر زمان عبارت‌اند از:
۱- زمان شروع و پایان توسعه
۲- میزان منابع در دسترس در زمان توسعه
۳- هزینه منابع
۳- مبلغی که افراد حاضر به پرداخت آن برای محصول هستند
۴- ریسک‌های موجود
۵- احتمال وقوع این ریسک‌ها و میزان تاثیر آنها بر هزینه
تاخیر و تسریع در شروع توسعه و مقادیر بالا بر سود محصول تاثیرگذار است بنابراین هزینه تاخیر تنها عامل تعیین کننده اولویت دهی اقلام سید نیست و باید زمان را که تاثیری بر مقادیر هزینه، سود، دانش و ریسک را دارد نیز در نظر گرفت.
یکی از راه‌های محاسبه هزینه تاخیر برابر با جمع سه عامل زیر است:
۱- ارزش کاربری: ارزش بالقوه از نگاه کاربر
۲- ارزش زمانی: چگونگی کاهش «ارزش کاربری» با گذشت زمان
۳- ارزش ناشی از کاهش ریسک یا استفاده از فرصت
به هر یک از این گزینه‌ها عددی مابین ۱ تا ۱۰ داده شده و جمع نهایی این سه برابر با جمع هزینه تاخیر است که میتوان با آن پروفایل هزینه تاخیر را بررسی کرد. تصویر اول در کامنت
برخی سازمانها تحت تاثیر قوانین خاص و سخت گیرانه نظارت شده هستند مانند سازمانهای تولید کننده محصولات پزشکی و بهداشتی، در این سازمان این عوامل میتواند از متغییرهای تاثیر گذار بر هزینه تاخیر باشد. برای مثال استاندارد ICD-10-CM نظام پزشکی ایالات متحده و رعایت قوانین U.S.HIPAA است
هزینه تاخیر عامل بسیار مهمی در اولویت بندی اقتصادی سبد بازسازی محصولات است
برآورد صحیح، نه دقیق
برای زمان بندی درست اقلام در بک لاگ سبد باید نسبت حجم کار به هزینه هر محصول را بدانیم. در ابتدای برآورد اطلاعات کمی در اختیار داریم لذا در برآورد هر قلم بدنبال صحت هستیم، نه دقت
در بخش‌های قبلی گفتیم سازمانها برای برآورد اقلام بجای اعداد از سایز استفاده میکنند (تصویر دوم در کامنت) که معادل هزینه محصول هستند که شامل حقوق و دستمزد کارکنان، مخارج سرمایه‌ای و سایر هزینه‌های تولید محصول است که معمولا بیشترین هزینه مربوط به حقوق است. مزیت رویکرد استفاده از سایز به اندازه مافی دقیق بودن آن است و اطلاعات مفیدی برای تصمیم گیری در سطح سبد محصول فراهم میکند
استراتژی‌های جریان ورودی
ترسیم چشم انداز به ما اطلاعات مفید و مورد نیاز برای تصمیم گیری اقتصادی در مورد ادامه یا توقف محصول فراهم میکند. و استراتژی جریان ورودی به ما در نحوه چگونگی اعمال فیلتر اقتصادی برای توقف یا ادامه محصول را میدهد و به موارد زیر نیز می‌پردازد
- ایجاد توازن بین نرخ ورود محصولات به سبد و نرخ خروج از آن
- روش استفاده از فرصت‌های نوظهور و جلوگیری از ایجاد گلوگاه در سبد محصول با استفاده از انتشارهای کوچکتر و زود به زود
۱- اعمال فیلتر اقتصادی
خروجی ترسیم چشم انداز، عبارت است از سند چشم‌انداز محصول و اطلاعات لازم برای شفاف سازی.
این خروجی شامل داده‌های مربوط به محصول جدید است که بعنوان ورودی برنامه ریزی استفاده میشود که سازمان بر اساس آن تصمیم به ادامه یا توقف محصول را میگیرد.
هر سازمان فیلترهای اقتصادی مخصوص بخود را دارد اما یک فیلتر خوب باید فرصت‌هایی که نسبت ارزش به هزینه آنها چشم گیر است را به سرعت تایید کند و هرچیزی غیر از این را رد کند مگر در شرایط خاص (اگر ارزش محصول هزینه را پوشش میدهد آن را در سبد محصول قرار دهید، اگر بحث مبلغ ناچیز است آن را رد کنید)
۲- ایجاد توازن بین نرخ ورود و نرخ خروج
در عمل انتظار داریم یک جریان پیوسته در ورود اقلام به سبد و خروج آن برقرار باشد و از طرفی هم نمی‌خواهیم افزودن یکباره تعداد زیادی از محصولات، بک لاگ محصولات را شلوغ کنیم، چنین کاری فشار قابل توجهی به سیستم وارد میکند. اکثر سازمانها تصمیمات اقتصادی خود را در سه ماهه سوم سال با یک رویداد برگزار میکنند و محصولات زیادی را در سبد قرار می‌دهند که منجر به اختلال میشود
#scrum
@code_crafters
👍4❤1
این رویکرد زمانی مناسب است که با عدم قطعیت بالا در سازمان روبرو باشیم
اغلب سازمانها برنامه استراتژیک سالانه خود را در سه ماه سوم سال برگذار میکنند و یکی از این نتایج فهرست محصولاتی است که می‌خواهند روی آن کار کنند. این محصولات باهم در بک‌لاگ سبد محصول وارد شده و موجب اختلال در برنامه ریزی سبد محصول می‌شوند
رویکرد استراتژیک خوب است اما نباید موجب اختلال در تصمیم گیری بک‌لاگ سبد محصول شود که تصمیمی برگشت ناپذیر است. این تصمیم‌ها زمانی گرفته میشود که با عدم قطعیت بالا روبرو هستیم و موجب نقض اصل باز نگه داشتن انتخاب‌های تا لحظه آخر هم میشود. از طرفی انتخاب همه اقلام بک‌لاگ سبد محصول اصل انتخاب اقتصادی اندازه بسته‌ها را نیز لغو میکند. این پردازش بسته بزرگ کار بیهوده و کم هزینه است. در سبد کوچکتر هر ترکیب با اندکی دقت کاملا اقتصادی و به صرفه است
بهترین کار بجای ورود ناگهانی، بلکه ورود اندک و در بازه‌های مشخص کوتاه مدت است که منجر به کاهش هزینه و حجم کار بازنگری هم میشود
همچنین بهتر است روی محصولات کوچکتر تمرکز کنیم تا جریان ورودی و خروجی توازن داشته باشد. در حجم بالا میتوان از فیلترها و معیارهای پذیرش، سنجشی و اقتصادی سختگیرانه‌تری بهره ببریم که جریان ورودی را کنترل کند و موجب آزاد شدن محصول بعدی از بک‌لاگ سبد محصول با آهنگ منظمی گردد
۳-استقبال از فرصت نو ظهور
در برنامه ریزی سبد فرصت طلب باشید. فرصت نوظهور را بپذیرید. فرصتی که قبلا ناشناخته بوده یا احتمال وقوع آن به قدری کم بوده که تا به امروز ارزش سرمایه‌گذاری نداشته است. اقدام دیر در قبال فرصت‌ها موجب میشود بخش بزرگ ارزش اقتصادی را از دست بدهید.
شما نیاز دارید بک برنامه منظم و پیوسته همراه فیلتر اقتصادی موثر داشته باشید و در کنار آن از انتشارهای کوچک و سقف کار در جریان نیز بهره ببرید
۴-برنامه ریزی برای انتشارهای کوچک و زود به زود
انتشارات کوچکتر توجیه اقتصادی بهتری دارند و همواره موجب افزایش سود چرخه عمر محصول میشود. علاوه بر این از ایجاد «اثر کاروانی» نیز جلوگیری میکند، تصور کنید یک اسکانیا در مسیر وجود دارد و موجب شده که ماشین‌های کوچکتر وشت سر او صف طولانی تشکیل دهند این همان اثر کاروانی است که با ورود محصول بزرگ ایجاد میشود و دلیل آن استفاده از تمام ظرفیت جاده و مسیر است. محصولات بزرگ منابع زیاد و طولانی نیاز دارند و موجب صف تاخیر میشود که خود هزینه بردار است. راه جلوگیری از آن اعمال سیاست سازمانی است بزای مثال هیچ محصولی با حجم کاری بیش از نه ماه پذیرفته نمیشود مگر راه حلی برای شکستن آن در انتشارات کوچکتر پیدا شود. همچنین تصور عدم وجود انتشار دوم موجب میشود که جانب احتیاط را گرفته و ویژگی‌هایی اضافه کنیم که موجب بزرگ شدن محصول میشود
استراتژی جریان خروجی
این استراتژی به سازمانها کمک میکند تا تصمیم بگیرند چه زمانی یک محصول را از سبد محصول خارج کنند، سه استراتژی در این بخش
استراتژی اول
بجای افراد بیکار به کارهای ناتمام توجه کنید.
این اصل بیان میکند اتلاف منابع و خسارت ناشی از کارهای ناتمام بیشتر از بیکاری افراد به مراتب بیشتر است. شیوه مدیریت سبد محصول در اغلب سازمانها با این اصل در تناقض است.
شیوه رایج اما اشتباه شروع توسعه محصول:
این رویکرد همه افراد را مشغول نگه می‌دارد. نتیجه دیگر آن خطاپذیری و کند شدن کاری است که روی هر یک از محصولات انجام میشود. رویکرد بهتر انتخاب و شروع کار روی محصولی است که جریان کار مناسبی دارد و جریان کار دیگر محصولات جاری را مختل نمی‌کند، که ارتباط تنگاتنگی با استراتژی دوم دارد
استراتژی دوم
هرگز نباید محصولی را از سبد برداشت که فراتر از توان ماست (مدیر باهوش)، این رفتار منجر میشود ظرفیت اختصاص داده شده به هر محصول کاهش یابدکه منجر در تاخیر و کاهش کیفیت در تمامی محصولات میشود.
تعیین سقف مناسب کار در جریان چگونه است؟ قبلا گفتیم تیم‌ها واحد اندازه گیری هستند و باید از آنها استفاده نمود (اطلاع از تعداد تیم‌های اسکرام و توانایی آنها به ما کمک میکند تا تعداد و نوع فعالیت‌های که میتوان همزمان انجام داد را تعیین کنیم)
استراتژی سوم
قبل از شروع کار بر روی یک محصول منتظر بمانید تا تیم اسکرام کامل تشکیل شود (تیم ناقص، تیمی است که تخصص کافی برای تکمیل ویژگی‌ها را ندارد) اکثر سازمانها به اشتباه فقط دنبال پر کردن تایم و مشغول نگه داشتن تیم هستند و این منجر میشود که اجازه ورود محصول دیگری را بدهند که منجر به کند شدن و اتلاف میشود
#scrum
@code_crafters
اغلب سازمانها برنامه استراتژیک سالانه خود را در سه ماه سوم سال برگذار میکنند و یکی از این نتایج فهرست محصولاتی است که می‌خواهند روی آن کار کنند. این محصولات باهم در بک‌لاگ سبد محصول وارد شده و موجب اختلال در برنامه ریزی سبد محصول می‌شوند
رویکرد استراتژیک خوب است اما نباید موجب اختلال در تصمیم گیری بک‌لاگ سبد محصول شود که تصمیمی برگشت ناپذیر است. این تصمیم‌ها زمانی گرفته میشود که با عدم قطعیت بالا روبرو هستیم و موجب نقض اصل باز نگه داشتن انتخاب‌های تا لحظه آخر هم میشود. از طرفی انتخاب همه اقلام بک‌لاگ سبد محصول اصل انتخاب اقتصادی اندازه بسته‌ها را نیز لغو میکند. این پردازش بسته بزرگ کار بیهوده و کم هزینه است. در سبد کوچکتر هر ترکیب با اندکی دقت کاملا اقتصادی و به صرفه است
بهترین کار بجای ورود ناگهانی، بلکه ورود اندک و در بازه‌های مشخص کوتاه مدت است که منجر به کاهش هزینه و حجم کار بازنگری هم میشود
همچنین بهتر است روی محصولات کوچکتر تمرکز کنیم تا جریان ورودی و خروجی توازن داشته باشد. در حجم بالا میتوان از فیلترها و معیارهای پذیرش، سنجشی و اقتصادی سختگیرانه‌تری بهره ببریم که جریان ورودی را کنترل کند و موجب آزاد شدن محصول بعدی از بک‌لاگ سبد محصول با آهنگ منظمی گردد
۳-استقبال از فرصت نو ظهور
در برنامه ریزی سبد فرصت طلب باشید. فرصت نوظهور را بپذیرید. فرصتی که قبلا ناشناخته بوده یا احتمال وقوع آن به قدری کم بوده که تا به امروز ارزش سرمایه‌گذاری نداشته است. اقدام دیر در قبال فرصت‌ها موجب میشود بخش بزرگ ارزش اقتصادی را از دست بدهید.
شما نیاز دارید بک برنامه منظم و پیوسته همراه فیلتر اقتصادی موثر داشته باشید و در کنار آن از انتشارهای کوچک و سقف کار در جریان نیز بهره ببرید
۴-برنامه ریزی برای انتشارهای کوچک و زود به زود
انتشارات کوچکتر توجیه اقتصادی بهتری دارند و همواره موجب افزایش سود چرخه عمر محصول میشود. علاوه بر این از ایجاد «اثر کاروانی» نیز جلوگیری میکند، تصور کنید یک اسکانیا در مسیر وجود دارد و موجب شده که ماشین‌های کوچکتر وشت سر او صف طولانی تشکیل دهند این همان اثر کاروانی است که با ورود محصول بزرگ ایجاد میشود و دلیل آن استفاده از تمام ظرفیت جاده و مسیر است. محصولات بزرگ منابع زیاد و طولانی نیاز دارند و موجب صف تاخیر میشود که خود هزینه بردار است. راه جلوگیری از آن اعمال سیاست سازمانی است بزای مثال هیچ محصولی با حجم کاری بیش از نه ماه پذیرفته نمیشود مگر راه حلی برای شکستن آن در انتشارات کوچکتر پیدا شود. همچنین تصور عدم وجود انتشار دوم موجب میشود که جانب احتیاط را گرفته و ویژگی‌هایی اضافه کنیم که موجب بزرگ شدن محصول میشود
استراتژی جریان خروجی
این استراتژی به سازمانها کمک میکند تا تصمیم بگیرند چه زمانی یک محصول را از سبد محصول خارج کنند، سه استراتژی در این بخش
۱-توجه به کارهای ناتمام به جای افراد بیکار
۲-تعیین سقف برای کار در جریان
۳-منتظر ماندن برای تشکیل یک تیم کاما
استراتژی اول
بجای افراد بیکار به کارهای ناتمام توجه کنید.
این اصل بیان میکند اتلاف منابع و خسارت ناشی از کارهای ناتمام بیشتر از بیکاری افراد به مراتب بیشتر است. شیوه مدیریت سبد محصول در اغلب سازمانها با این اصل در تناقض است.
شیوه رایج اما اشتباه شروع توسعه محصول:
۱-محصول ردیف اول بک‌لاگ را بردارید و افرادی را برای انجام آن تعیین کنید
۲-آیا همه وقتشان پر شده است، اگر خیر گام اول را تکرار کنید
این رویکرد همه افراد را مشغول نگه می‌دارد. نتیجه دیگر آن خطاپذیری و کند شدن کاری است که روی هر یک از محصولات انجام میشود. رویکرد بهتر انتخاب و شروع کار روی محصولی است که جریان کار مناسبی دارد و جریان کار دیگر محصولات جاری را مختل نمی‌کند، که ارتباط تنگاتنگی با استراتژی دوم دارد
استراتژی دوم
هرگز نباید محصولی را از سبد برداشت که فراتر از توان ماست (مدیر باهوش)، این رفتار منجر میشود ظرفیت اختصاص داده شده به هر محصول کاهش یابدکه منجر در تاخیر و کاهش کیفیت در تمامی محصولات میشود.
تعیین سقف مناسب کار در جریان چگونه است؟ قبلا گفتیم تیم‌ها واحد اندازه گیری هستند و باید از آنها استفاده نمود (اطلاع از تعداد تیم‌های اسکرام و توانایی آنها به ما کمک میکند تا تعداد و نوع فعالیت‌های که میتوان همزمان انجام داد را تعیین کنیم)
استراتژی سوم
قبل از شروع کار بر روی یک محصول منتظر بمانید تا تیم اسکرام کامل تشکیل شود (تیم ناقص، تیمی است که تخصص کافی برای تکمیل ویژگی‌ها را ندارد) اکثر سازمانها به اشتباه فقط دنبال پر کردن تایم و مشغول نگه داشتن تیم هستند و این منجر میشود که اجازه ورود محصول دیگری را بدهند که منجر به کند شدن و اتلاف میشود
#scrum
@code_crafters
👍4
استراتژی محصولات جاری
این استراتژی در تصمیم‌گیری به ما کمک میکند کدام اقدام را انجام دهیم: حفظ، تغییر مسیر، تحویل یا توقف. که در پایان هر اسپرینت گرفته میشود و گاها در بازه‌های و هنگام وقوع رویدادهای غیرعادی، بازبینی، بازبینی محصولات جاری ضروری میشود. واحدهای حاکمیتی شازمان استراتژی‌های متفاوتی دارند که یکی از این موارد «مطلوبیت اقتصاد نهایی» است که با اصول اسکرام و چابکی سازگار است و باید در تصمیم گیری‌ها مورد استفاده قرار گیرد
استفاده از مطلوبیت اقتصاد نهایی
تمام کارهای انجام شده تا قبل از لحظه تصمیم گیری، هزینه برگشت ناپذیر است. برای گام بعدی مطلوبیت اقتصاد نهایی مدنظر است، که با این سوال که آیا هزینه کردن سرمایه با توجه به بازدهی آینده توجیه پذیر است.
این دیدگاه به چهار انتخاب اصلی میدهد:
اگر سرمایه گذاری توجیه دارد در حالت حفظ قرار می‌گیریم، این سناریو زمانی رخ میدهد که یکی از محصولات جاری را بازنگری کنیم
در غیر این صورت باید رو سه حالت دیگر تصمیم گرفت
اگر محصول کمینه ویژگی‌های قابل انتشار را داراست حالت تحویل، در غیر این صورت مسیر اشتباه پیش رفته‌ایم، و اگر فکر کنیم مسیر دیگری ارزش اکتشاف داشته باشد حالت تغییر مسیر، اگر سرمایه گذاری توجیه ندارد و از موقعیت خود نیز رضایت نداریم حالت توقف
#scrum
@code_crafters
این استراتژی در تصمیم‌گیری به ما کمک میکند کدام اقدام را انجام دهیم: حفظ، تغییر مسیر، تحویل یا توقف. که در پایان هر اسپرینت گرفته میشود و گاها در بازه‌های و هنگام وقوع رویدادهای غیرعادی، بازبینی، بازبینی محصولات جاری ضروری میشود. واحدهای حاکمیتی شازمان استراتژی‌های متفاوتی دارند که یکی از این موارد «مطلوبیت اقتصاد نهایی» است که با اصول اسکرام و چابکی سازگار است و باید در تصمیم گیری‌ها مورد استفاده قرار گیرد
استفاده از مطلوبیت اقتصاد نهایی
تمام کارهای انجام شده تا قبل از لحظه تصمیم گیری، هزینه برگشت ناپذیر است. برای گام بعدی مطلوبیت اقتصاد نهایی مدنظر است، که با این سوال که آیا هزینه کردن سرمایه با توجه به بازدهی آینده توجیه پذیر است.
این دیدگاه به چهار انتخاب اصلی میدهد:
حفظ: ادامه توسعه محصول
تحویل: توقف کار و تحویل محصول
تغییر مسیر: ثبت آموخته‌ها و تغییر سمت و سوی آینده محصول
توقف: اتمام کار و کنار گذاشتن محصول
تصویر اول در کامنت‌ها
اگر سرمایه گذاری توجیه دارد در حالت حفظ قرار می‌گیریم، این سناریو زمانی رخ میدهد که یکی از محصولات جاری را بازنگری کنیم
در غیر این صورت باید رو سه حالت دیگر تصمیم گرفت
اگر محصول کمینه ویژگی‌های قابل انتشار را داراست حالت تحویل، در غیر این صورت مسیر اشتباه پیش رفته‌ایم، و اگر فکر کنیم مسیر دیگری ارزش اکتشاف داشته باشد حالت تغییر مسیر، اگر سرمایه گذاری توجیه ندارد و از موقعیت خود نیز رضایت نداریم حالت توقف
هیچگاه اجازه ندهید که تصمیمات حسابداری شما را به رفتار نابخردانه بکشاند
#scrum
@code_crafters
👍5