مدیریت پروژه چابک: متدولوژی اسکرام

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

اسکرام چیست؟
اسکرام چارچوب (Framework) منعطف و مشارکتی مدیریت پروژه چابک است که برای رفع محدودیت های روش های مدیریت پروژه سنتی و تسهیل توسعه و تحویل سریع پروژه های پیچیده طراحی شده است و به ما کمک می کند تا در کنار هم به عنوان یک تیم کار بکنیم. به جای برنامه ریزی گسترده، برنامه های سفت و سخت و جلسات بی پایان، اسکرام بر همکاری، انعطاف‌پذیری و پاسخگویی تأکید دارد و آن را به ‌ویژه برای صنایع ای که تغییر ثابت است، مانند استارت ‌آپ ‌ها و توسعه نرم ‌افزار، مناسب می‌کند. اسکرام یک رویکرد پویا و تکراری را ترویج می کند. اسکرام با تقسیم پروژه ها به واحدهای کوچکتر و قابل مدیریت به نام تکرار (Sprints)، جایگزین رویکرد سنتی آبشار می شود.
اسکرام به عنوان پر کاربرد ترین و قوی ترین پیاده سازی برای طرز فکر چابک که تمرکز اصلی آن بر توسعه نرم افزار است برای اولین بار توسط کن شوابر و جف ساترلند در اوایل دهه ۱۹۹۰ معرفی شد (اولین نسخه آن سال ۲۰۱۰ برای استفاده عموم وارد بازار شد) و از آن زمان تا به امروز اسکرام توسط خیلی از شرکت های مطرح دنیا استفاده می شود.

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

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

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

اسکرام کار را به یک تیم یادگیری انعطاف پذیر منتقل می کند و از جابجایی افراد یا تقسیم آنها بین تیم ها اجتناب می کند.

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

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

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

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

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

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

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

چرخه دمینگ و اسکرام:
چرخه دمینگ که به عنوان چرخه Plan-Do-Check-Act (PDCA) نیز شناخته می شود، یک چارچوب بهبود مستمر است که نقش مهمی در متدولوژی اسکرام ایفا می کند و برای حفظ و افزایش کیفیت و اثربخشی فرآیند ها و محصولات چابک ضروری است. در اینجا اهمیت چرخه دمینگ در متدولوژی اسکرام آورده شده است:

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

با ادغام چرخه دمینگ در شیوه های خود، تیم های اسکرام می توانند فرآیندهای خود را بهبود بخشند، با نیازهای متغیر سازگار شوند و نرم افزارهای ارزشمند را به طور مداوم به مشتریان خود ارائه دهند.

تعریف کار انجام شده یا Definition of Done (DoD):
تعریف کار انجام شده یک قرارداد مستند و یک مفهوم انتقادی در اسکرام است و شرایط و معیارهایی را که یک داستان کاربر باید داشته باشد، استاندارد های لازم برآورده شوند، کامل تلقی شود و از انباشت بدهی فنی جلوگیری شود و کامل و آماده تحویل است. DoD تضمین می کند همه متوجه شوند یک کار چه زمانی تمام شده است (درک مشترک در تیم اسکرام) و توسعه انجام شده بر روی محصول برای بررسی آماده است (کار روی آیتم مخزن محصول کار انجام شده) و به طور بالقوه قابل ارسال در نظر گرفته شود. برای اطمینان از کیفیت خروجی خود، تیم های چابک به تعریف انجام شده پایبند هستند.این استاندارد را در ابتدا شرکت یا سازمان و سپس تمام تیم های Scrum مشخص می کنند.
یکی از جنبه های مهم اسکرام تجسم پیشرفت است. تیم ها اغلب از یک تخته اسکرام استفاده می کنند که به ستون هایی تقسیم می شود که مراحل کار را نشان می دهد، مانند "To-Do"، "In Progress" و"Done". هر کار یا نیاز با کارتی نشان داده می شود که با پیشرفت کار در این ستون ها حرکت می کند. این تصویر واضحی از پیشرفت تیم ارائه می دهد و به شناسایی هر گونه تنگنا یا مانع کمک می کند.

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

داستان کاربر: ‌(User Story)
داستان کاربر یا User Story روشی مشتری محور برای بیان نیازها در اسکرام است. این معمولاً یک توصیف یک یا دو جمله ای است که یک عملکرد یا ویژگی خاص را از دیدگاه کاربر نهایی بیان می کند. یک داستان کاربر معمولاً از قالب پیروی می کند:
"به عنوان یک [نوع کاربر]، من [یک عمل] را می ‌خواهم تا [منفعت یا ارزش] را داشته باشد."
به عنوان مثال، "به عنوان یک بازدید کننده وب سایت، می خواهم بتوانم رمز عبور خود را باز نشانی کنم تا بتوانم دوباره به حساب خود دسترسی پیدا کنم."
داستان ‌های کاربر عمداً مختصر هستند و به عنوان مکان ‌هایی برای مکالمات دقیق بین مدیر محصول (Product Owner) و تیم توسعه (Development Team) عمل می‌کنند. این مکالمات در طول برنامه ‌ریزی اسپرینت یا اصلاحا Backlog برای روشن شدن جزئیات داستان کاربر، معیارهای پذیرش و هرگونه ملاحظات فنی انجام می‌شود. داستان های کاربر برای حفظ تمرکز بر ارائه ارزش به کاربران نهایی و حصول اطمینان از اینکه تیم توسعه هدف و زمینه کاری که انجام می دهند را درک می کند، بسیار مهم است. آنها همچنین به تجزیه ویژگی های بزرگتر به قطعات کوچکتر و قابل مدیریت کمک می کنند.

امتیاز داستان: (Story Point)
امتیاز داستان یک تکنیک تخمین نسبی است که در اسکرام برای اندازه‌گیری اندازه میزان پیچیدگی داستان ‌های کاربر (User Story) یا سایر موارد کاری استفاده می‌شود. امتیاز داستان یک معیار بدون واحد هست و معمولا در طول جلسه برنامه ریزی اسپرینت به داستان های کاربر اختصاص داده می شوند.
تیم ها بر اساس درک خود از پیچیدگی، تلاش و خطرات بالقوه کار، نقاط داستانی را تعیین می کنند. مقیاس های رایج برای نقاط داستان شامل دنباله فیبوناچی ( ...،۱،۲،۳،۵،۸) یا یک مقیاس خطی (...،۱،۲،۳،۴ ) است.
امتیاز داستان برای مقایسه اندازه ‌های نسبی داستان‌ های کاربران مفید هستند، که به تیم‌ها کمک می‌کند تا میزان کاری را که می‌توانند در یک Sprint انجام دهند تعیین کنند و دقت تخمین خود را در طول زمان بهبود بخشند.
توجه به این نکته مهم است که نقاط داستان نشان دهنده زمان نیستند. در عوض، آنها قضاوت جمعی تیم را در مورد پیچیدگی و تلاش کار منتقل می کنند. این رویکرد به تیم‌ها اجازه می‌دهد تا به جای غرق شدن در تخمین‌ های زمانی دقیق، بر ارائه ارزش تمرکز کنند.

از آنجایی که بیشتر مشتریان از اکثر ویژگی‌های محصول استفاده نمی‌کنند، عاقلانه است برای ارائه با ارزش‌ترین داستان‌ها ابتدا داستان‌ ها را تقسیم کنیم. داستان های ابتدایی ۸۰٪ ارزش تجاری در مقابل ۲۰٪ تلاش ها است.

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

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

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

محور X (افقی): محور x نشان‌دهنده زمان است که معمولاً در روز یا تعداد افزایش‌ های کاری اندازه‌گیری می‌شود (به عنوان مثال، Daily Sprints، Sprints و ...).
محور Y (عمودی): محور y میزان کار باقی مانده را نشان می دهد. این اغلب در بخش ارزیابی امتیاز داستان اندازه گیری می شود، اما همچنین می تواند بر حسب ساعت یا واحدهای مرتبط دیگر باشد.
خط Ideal Burndown: این یک خط مورب است که از کل کار برنامه ریزی شده برای Sprint در ابتدا شروع می شود (به عنوان مثال، کل نقاط داستان یا ساعت ها) و در پایان Sprint به صفر می رسد. این نشان دهنده پیشرفت ایده آل است اگر تیم کار را با سرعت ثابتی در طول اسپرینت کامل کند.
خط Actual Burndown: این خط پیشرفت واقعی تیم را از نظر کار انجام شده نشان می دهد. این بر اساس داده های واقعی است و نشان می دهد که چگونه کار در طول اسپرینت انجام می شود.

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

ضروریات اسکرام:
در هسته خود، اسکرام یک چارچوب سبک وزن است که درک آن ساده است اما تسلط بر آن چالش برانگیز است. این در صنایع مختلف به کار گرفته می شود، به طوری که تخمین زده می شود در ۵ سال آینده ۹۰٪ از تیم های چابک، اسکرام را به عنوان چارچوب خود انتخاب کنند. چارچوب اسکرام توسط یک منبع معتبر شناخته شده به عنوان راهنمای اسکرام تعریف می شود و یکنواختی را در کاربرد آن تضمین می کند. بنابراین، بیایید سفری را برای کشف دنیای اسکرام آغاز کنیم.

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

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

1. Product backlog 2. Sprint backlog 3. Sprint increment

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

۲. اسپرینت بک لاگ: (Sprint Backlog) هر اسپرینت با یک بک لاگ اسپرینت شروع می شود و زیر مجموعه ای از داستان های کاربر از بک لاگ محصول است که برای اسپرینت آینده انتخاب می شود و تیم توسعه را در سرتاسر اسپرینت هدایت می کند. این شامل یک برنامه واضح از داستان های کاربر، وظایف، و سایر موارد کاری است که تیم توسعه متعهد به تکمیل آنها در طول اسپرینت است. اسپرینت بک لاگ با همکاری تیم توسعه در طول جلسه برنامه ریزی اسپرینت ایجاد می شود و متعلق به تیم توسعه است و آنها مسئول تحویل موارد کاری در اسپرینت هستند. با اینکه اسپرینت بک لاگ یک لیست با اولویت بندی دقیق از کارهای آماده برای اقدام فوری، اما در واقع این یک پیش بینی است تا یک تعهد، تیم های سالم قصد دارند بین ۸۵٪ الی ۱۱۵٪ از کارهای برنامه ریزی شده را تکمیل کنند.

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

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

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

نقش های اسکرام: (Scrum Roles)
در اسکرام، هر یک از اعضای تیم تشویق می‌شود که عملکردی متقابل داشته باشند. این بدان معناست که هر عضو می تواند در جنبه های مختلف پروژه مانند توسعه، آزمایش و طراحی مشارکت داشته باشد. این رویکرد تضمین می کند که تیم می تواند حتی اگر یکی از اعضا در دسترس نباشد به کار خود ادامه دهد و خود سازماندهی و انعطاف پذیری را ارتقا دهد. اعضای یک تیم اسکرام برای این که بتوانند مصنوعات (Artifacts) خود به نحو احسن انجام دهد نیاز به یک سری نقش های اصلی دارد. تیم اسکرام متشکل از ۴ تا ۹ نفر حرفه ای با مهارت های متنوع با قابلیت خود سازماندهی برای تکمیل کار هستند. اعضای تیم اسکرام شامل Product Owner، Scrum Master و Development Team می باشد. اعضای تیم افرادی هستند که به طور فعال در طراحی، توسعه و ارائه پروژه مشارکت دارند و برای تکمیل داستان‌ های کاربر در داخل اسپرینت با یکدیگر همکاری می‌کنند. در نظر داشته باشید هیچ سلسله مراتبی در اسکرام وجود ندارد. مالک محصول یا اسکرام مستر به هیچ عنوان مدیران تیم نیستند. همه ی اعضای تیم از نظر سلسله مراتب در یک سطح برابر قرار می گیرند. تیم اسکرام به صورت خود مختار و بر اساس این که چه کسی؟ چه زمانی؟ چه کاری؟ را انجام دهد خود را مدیریت می کند. در اسکرام، نقش ها برای اطمینان از وضوح و اثربخشی به خوبی تعریف شده اند.

1. Product Owner 2. Scrum Master 3. Development Team

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

- هیچ User Story نباید در طول اسپرینت توسط مالک محصول به پروژه اضافه شود مگر توسط تیم توسعه در خواسته اضافه شدن User Story به پروژه اضافه شود اما تیم اسکرام می تواند در طول اسپرینت آیتم های جدیدی را به مالک محصول پیشنهاد دهد. (مثلا یک Technical Story یا تغییراتی مثل تغییر یک class یا بهتر کردن Data Base)
- این که مالک محصول به جای این که به تیم بگوید چه (What) کاری باید انجام شود، در نحوه انجام و چگونگی انجام کار (How) دخالت کند اشتباه است.
- این که مالک محصول با توجه به دید عملی و کسب و کار عالی در طول اسپرینت از تیم فاصله بگیرد و به تیم کمک نکند یک اشتباه بزرگ برای تیم اسکرام محسوب می شود. در واقع مالک محصول در طول اسپرینت دید کلی از هدف تیم به سایر اعضای تیم می دهد.
- گذاشتن فشار روی تیم توسعه توسط مالک محصول یک اشتباه بزرگ است که کیفیت محصول را تا حد زیادی فدای سرعت انجام کار می کند.
- مالک محصول مسئول اعلام اینکه کدام اقلام برای کسب و کار مهم هستند.

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

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

تیم توسعه: (Development Team) تیم توسعه متشکل از متخصصان با مهارت های متنوع با استعداد، از جمله توسعه دهندگان، تست کنندگان، کارشناسان در تجربه کاربری، تضمین کیفیت، عملیات و... هست که با همکاری با یکدیگر دیدگاه مالک محصول را به یک واقعیت ملموس تبدیل می کنند. اعضای تیم اغلب نقش های متعددی مانند بک اند، فرانت اند، دیتابیس، UI/UX ، تست و هر کار دیگری که نیاز است پروژه را به سر انجام برساند را بر عهده می گیرند (کار در تیم به صورت چند مهارتی یا Cross-functional می باشد) و با هم کار می کنند. آنها پشت هزاران خط کد قرار دارند و با پشتکار تلاش می کنند تا محصول را زنده کنند و افزایش دهند.آنها کار خود را در طول یک اسپرینت سازماندهی و مدیریت می کنند و به هدف اسپرینت و کار در اسپرینت بکلاگ متعهد می شوند.
تیم توسعه تیمی است که خودش را مدیریت، وابستگی به خارج از تیم اسکرام ندارد و وقتی نیاز به یک قابلیت حس شد تمام تیم در کنار مالک محصول یا اسکرام مستر زمانی را برای یادگیری قابلیت ها اختصاص می دهند. بعد از یادگیری آن قابلیت خاص آیتم هایی را که مربوط به آن قابلیت می شود از بک لاگ بر میدارند.

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

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

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

1. Sprint 2. Sprint Planning 3. Daily Scrum 4.Sprint Review
5. Sprint Retrospective 6. Backlog Refinement

۱. اسپرینت: (Sprint) اسپرینت یا به اختصار تکرار توسعه با جعبه زمانی، قلب تپنده اسکرام هست و اسکرام بر اساس اسپرینت است. به صورت اختصار هر تکراری که در طول آن یک محصول به مشتری تحویل داده می شود یا یک ارتقا روی محصول داریم Sprintنامیده می شود. در روش مدیریت پروژه تکرار شونده کل پروژه را به تکه های کوچک تر تقسیم می شود و بعد در طول تکرارهای (Sprint) محدود به زمان (تمام اسپرینت ها از یک الگوی زمانی پیروی می کنند)، یک قسمت از محصولی که مشتری به آن احتیاج دارد (تکمیل مجموعه ای داستان های شناسایی شده کاربر به ترتیب موارد اولویت ‌دار از Backlog محصول) به آن ارائه می شود تا یک افزایش محصول بالقوه قابل حمل ایجاد کند. به هر کدام از این تکرار ها در اسکرام Sprint می گوییم. هر Sprint در طول هر تکرار ۲،۱ یا ۴ هفته است و باید زمان اتمام تمام اسپرینت ها در پروژه به یک میزان باشند (بهینه ترین حال هر ۲ هفته است زیرا باعث تکرار سریع در انجام پروژه می‌شود و از ایجاد ضد الگوهای مضر جلوگیری می‌کند.). شروع هر اسپرینت دقیقا روز بعد از اتمام اسپرینت قبلی اتفاق می افتد (همه Sprint ها به هم چسبیده و پشت سر هم اتفاق می افتند و بینشان فاصله ای نیست). همانطور که گفته شدUser Story ها در داخل Product Backlog قرار دارند. در هر Sprint ما از Product Backlog اصلی یک سری آیتم بر می داریم (به آنها User Story می گویند) و در Sprint استفاده می کنیم. (Product Owner مسئول فرم دهی به Backlog هست). اسپرینت ها فرصتی را برای ایجاد یک محصول بالقوه قابل حمل در یک بازه زمانی کوتاه فراهم می کنند و تا زمانی که محصول کامل شود ادامه می یابند و امکان سازگاری و بهبود مستمر را فراهم می کند. برنامه ریزی با اسپرینت شروع می شود و با بررسی اسپرینت و بازنگری اسپرینت به پایان می رسد.

حداکثر زمان تخصیص داده شده (Time Box) به یک اسپرینت ۳۰ روز می باشد (هشت ساعت زمان لازم برای برنامه ریزی لازم است)

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

با توجه به تعداد و وزن User Story ها اسکرام مستر با توجه به کیفیت، تعداد و قابلیت تیم به مالک محصول تعداد Story Point ها قابل انجام در اسپرینت را گزارش می دهد. مالک محصول با توجه با Product Backlog خود به ترتیب از اولویت اول را انتخاب می کند و تا جایی که وزن Story Point ها به عدد مذکور برسد ادامه می دهد و آنها را برای تیم توسعه مشخص می کند. سپس مالک محصول با کل تیم شروع به بررسی موارد می کند تا ماهیت و هدف اسپرینت را به طور کامل درک کنند. در نهایت Sprint Backlog بین اعضای تیم توسعه توزیع می شود.

۳. اسکرام روزانه: (Daily Scrum / Daily Standup) در طول اسپرینت هر روز، یک زمان ثابت از روز و در یک مکان مشخص یک جلسه ایستاده مختصر به مدت ۱۵ دقیقه، تمام تیم اسکرام دور هم جمع می شوند و در مورد شرایط کنونی پروژه، پیشرفت، برنامه ها و موانع پیش رو صحبت می کنند. این که دیروز چه کاری انجام دادند، در حال انجام چه کاری هستم و موانع و مشکلاتی که با انها روبرو هستم یا احتمال دارد با آن مواجه شود را توضیح می دهد. Daily Scrum جلسه اعتراف گیری نیست بلکه یک رویکرد برای شفاف سازی Sprint انجام می شود. در آن اعضای تیم به سه سوال کلیدی پاسخ می دهند: "دیروز چه کار کردید؟"، "امروز چه خواهید کرد؟" و "آیا موانعی بر سر راه شما وجود دارد؟". این باعث شفافیت، همسویی و حل سریع مشکلات می شود و تیم را در یک راستا نگه می دارد و امکان حل سریع مشکلات را فراهم می کند.

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

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

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

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

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

۶. پالایش معوقات: (Backlog Refinement یا Grooming Meeting) در حالی که یک رویداد رسمی نیست، این جلسه به بررسی و تخمین آیتم های بک لاگ اصلی می پردازد(چه زمانی بک لاگ محصول را اصلاح می کنیم؟ هدف از این جلسه چیست؟ چه کسی شرکت می کند؟). آیتم هایی که داخل Product Backlog هستند (User Story) تخمین میخورند تا بفهمیم هر User Story چقدر زمان احتیاج دارد و بعد در طول Sprint Planning بر اساس این تخمین ها از آیتم ها استفاده می کنند. اصلاح بک لاگ یک فعالیت همیشکی در حال انجام است که در آن مالک محصول و تیم توسعه با یکدیگر همکاری می کنند تا موارد موجود در بک لاگ محصول را اصلاح و شفاف کنند تا آنها را برای اسپرینت های آینده آماده کنند.

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

پنج ارزش بنیادین در اسکرام:

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

• تعهد باعث تقویت اعتماد در تیم و با سهامداران می شود. این تضمین می کند که همه در جهت دستیابی به اهداف یکسان هستند و تیم را تشویق می کند تا به طور مداوم به تعهدات خود عمل کند.

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

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

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

• تمرکز تضمین می کند که تیم در پایان هر اسپرینت یک محصول بالقوه قابل حمل را ارائه می دهد. این به تیم کمک می کند تا ارزش ارائه شده به مشتریان و ذینفعان را به حداکثر برساند.

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

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

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

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

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

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

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

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

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

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

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

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

اسکرام در مقیاس بزرگ (LeSS) چیست؟
اسکرام در مقیاس بزرگ یا LeSS فقط یک چارچوب دیگر نیست. این یک رویکرد متحول کننده برای مقیاس بندی اصول توسعه چابک برای پروژه های بزرگ و پیچیده است. LeSS در رویکرد خود به توسعه محصول در مقیاس بزرگ بر سادگی و مشتری محوری تأکید دارد. بر اساس این ایده است که پیچیدگی کمتر در فرآیندها و ساختارها منجر به ایجاد سازمان ‌های مؤثرتر و سازگارتر می‌شود. در هسته خود، LeSS یک اسکرام چند تیمی است. ایجاد یک محصول یکپارچه در هر اسپرینت را ترویج می کند که معمولاً بین ۱ تا ۴ هفته است. این محصول یکپارچه بازتابی از اقلام مشتری محور است که به طور دقیق بر روی بک لاگ محصول اولویت بندی شده است، تحت هدایت یک مالک محصول با چشم انداز روشن.
هر اسپرینت با Sprint Planning 1 آغاز می‌شود، یک رویداد مشترک که در آن چندین تیم ویژگی‌ هایی را از بک لاگ محصول برای اجرا در طول اسپرینت انتخاب می‌کنند. پس از آن Sprint Planning 2 دنبال می‌شود، جایی که تیم‌ها در مورد چگونگی توسعه این ویژگی ‌ها استراتژی می‌کنند.
در سرتاسر اسپرینت، تیم‌های خود مدیریت بر روی ویژگی‌های انتخابی خود کار می‌کنند و به طور مداوم کار خود را با سایر تیم‌ها ادغام می‌کنند تا یک افزایش بالقوه روی محصول تولید کنند. چیزی که در مورد LeSS منحصر به فرد است این است که هیچ هماهنگ کننده مشخصی وجود ندارد. تیم ها مسئول هماهنگی خود هستند.
در اواسط راه اسپرینت، تیم‌ها کار فعلی خود را برای اصلاح بک لاگ محصول برای مدت کوتاهی متوقف می‌کنند. این مرحله شامل همکاری با مشتریان و کاربران نهایی برای شفاف‌ سازی کار برای اسپرینت‌ های آینده است و به مالک محصول اجازه می‌دهد بر روی چشم ‌انداز و اولویت‌بندی تمرکز کند.
اسپرینت با بررسی مشترک اسپرینت به پایان می رسد، جایی که تیم ها و مشتریان آنچه را که انجام شده است ارزیابی می کنند و در مورد افزایش بعدی برای توسعه تصمیم می گیرند. سپس تیم‌ها برای بازرسی و انطباق فرآیندهای خود، مروری به گذشته انجام می‌دهند. مالکیت روش ها و فرآیندها کلید بهبود مستمر در LeSS است. فراتر از مرور های گذشته در سطح تیم، LeSS یک بازنگری کلی را تشویق می کند که شامل تیم ها، مالک محصول، اسکرام مسترها و مدیریت می شود. این گذشته نگر بزرگتر بر شناسایی موانع سیستمی و سازمانی که مانع ارائه ارزش می شوند تمرکز دارد. LeSS به گروه های کوچک محدود نمی شود. این مقیاس متناسب با نیازهای سازمان‌ هایی با بیش از هشت تیم ( که به آن LeSS Huge می‌ گویند) با هدف اصلی یکسان ارائه یک محصول کامل در هر اسپرینت ایجاد می شود.

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

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

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

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

سوالات متداول اسکرام (FAQ)

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

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

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

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

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

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

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

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

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

آیا وظیفه اسکرام مستر این است که افراد را مدیریت کند تا مطمئن شود که «تنبل» نیستند؟ خیر، اسکرام مستر محیطی را برای خود سازماندهی تیم ایجاد می کند.

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

آیا برآوردها در اسکرام اهمیت دارند؟ واقعاً نه. تیم ها باید از احساس خود در طول جلسه برنامه ریزی اسپرینت استفاده کنند تا تصمیم بگیرند کدام آیتم های بک لاگ محصول (Product Backlog) را در یک اسپرینت امتحان کنند.

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

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

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

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

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

سناریو های ماژول یک تیم را توصیف می کنند. در مورد سازمان های بزرگ چطور؟ Danube Technologies, Inc که بعدها توسط CollabNet خریداری شد زمانی که ده سال پیش شروع به انجام اسکرام (و اقدامات فنی مرتبط) برای توسعه خود کرد، یک شرکت کوچک بود. نسبتا آسان بود زیرا عادت ‌های تثبیت‌ شده زیادی برای غلبه بر آن وجود نداشت. در حالی که افراد در سازمان ‌های بزرگ مزایای اسکرام یا ذهنیت چابک را تجربه کرده ‌اند، ما ندیده ‌ایم که بسیاری از سازمان ‌های بزرگ در اولین تلاش موفق به انجام این کار شوند. توزیع جغرافیایی را اضافه کنید، مشکل حتی سخت تر می شود. گاهی اوقات بهترین کاری که می ‌توانیم انجام دهیم این است که از یک تیم در برابر بقیه بوروکراسی محافظت کنیم تا زمانی که آن تلاش آزمایشی نشان دهد که ممکن است برای دیگران مزایایی داشته باشد.
همچنین ممکن است چندین تیم با استفاده از رویکرد چابک برای کار بر روی یک محصول داشته باشید. اکثر مربیانی که با سازمان ‌های بزرگی که سعی در چابکی دارند کار کرده ‌اند، تیم‌های ویژه را بر تیم‌های جزء ترجیح می‌دهند. تیم‌های ویژگی بر روی چندین مؤلفه کار می‌کنند تا ویژگی ‌هایی را که کاربران نهایی می‌توانند ببینند، به جای تحویل‌ های داخلی صرف، ارائه دهند. متأسفانه سازمان ‌های بزرگ به ‌طور سنتی مانند کارخانه‌ ها راه ‌اندازی می‌شوند، با افراد سازمان ‌دهی شده حول اجزای معماری (مانند سمت سرور و سمت مشتری) یا گروه ‌بندی شده بر اساس نظم و انضباط عملکردی (مثلاً یک بخش Q.A. در کشوری دیگر). در ساختار سنتی، برای هر تیمی دشوارتر است که کار را به حالت تحویل مشتری برساند. این امر صاحبان محصول را وادار می کند تا به جای ارزش تجاری مشتری، محدودیت های داخلی را اولویت بندی کنند. در حالی که رویکرد تیم ویژه چابک ‌تر است، اما چالش ‌های سیاسی و فنی را ارائه می‌کند. ممکن است لازم باشد از افراد بخواهیم که به عنوان نگهبان اجزاء برای محافظت از یکپارچگی معماری اجزای خاص در طول انتقال عمل کنند. من فکر می ‌کنم یک محافظ قطعه به‌عنوان یک راهنمای تور برای یک قطعه، به تیم‌های ویژگی نشان می‌دهد که چگونه از کامپوننت استفاده کنند و در عین حال مطمئن می‌شوند که در این فرآیند آن را خراب نمی ‌کنند.

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

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

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

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

آیا [شرکت موفق معروف XYZ] اسکرام را انجام می دهد؟ اسکرام تنها یک راه برای رسیدن به چابکی است، درست مانند رفتن به باشگاه تنها یک راه برای خوش اندام شدن. برخی شرکت‌ های غیرقابل انطباق وجود دارند که «اسکرام» را انجام می‌دهند (یا حداقل می ‌گویند که دارند) و برخی شرکت ‌های دیگر هستند که ارزش ‌های چابک را به طور طبیعی و بدون انجام اسکرام انجام می‌دهند. موانع یک سازمان یکسان هستند، چه آنها را با اسکرام، ناب، کانبان، XP یا هر رویکرد دیگری که به تفکر دعوت می کند، افشا کنیم. توجه داشته باشید که امروزه برخی از شرکت های "موفق" وجود دارند که تنها به دلیل شتاب در حال حاضر زنده می مانند. عامل واقعی در رقابتی ماندن فردا این است که آیا ما از حلقه های بازخورد خود (مانند بررسی Sprint و Sprint Retrospective) برای یادگیری و تطبیق سازمان خود استفاده خواهیم کرد یا خیر.

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

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

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

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