اسکرام یک چارچوب یا فریمورک برای انجام و مدیریت پروژه است. فریم ورک اسکرام مجموعه‌ای از ابزارها، نقش‌ها و فرایندهاست که به تیم‌ها کمک می‌کند تا به بهینه‌ترین شکل ممکن پروژه توسعه محصول را به سرانجام برسانند.
با نگاهی سرسری به مطالب این یادداشت ممکن است با دیدن انبوهی از اصطلاحات نو، اختصاصی و انگلیسی روبرو شوید اما جای نگرانی نیست؛ با یک دور مطالعه به‌راحتی تمامی این مفاهیم را درک خواهید کرد.
معنی Scrum چیست؟
پیش از هر چیز بد نیست بدانیم واژه اسکرام از کجا می‌آید و معنای آن چیست؛ کلمه Scrum ریشه در بازی راگبی دارد. عبارت Scrummage (یا به طور خلاصه Scrum) به موقعیتی در ورزش راگبی اشاره دارد که در آن بازیکنان یک تیم برای شروع مجدد بازی و هجوم به حریف در کنار هم حلقه زده و به‌عنوان یک واحد یکدست و هماهنگ حرکت می‌کنند.
اسکرام چیست؟
ساده‌ترین تعریف ممکن از اسکرام اینه: «اسکرام» روشیه برای مدیریت کارها در یک تیم؛ این روش (فریمورک یا چارچوب) به‌خصوص برای پروژه‌های پیچیده مثل توسعه نرم‌افزار بسیار کاربردیه.
اگر کلمه اسکرام را در گوگل جستجو کرده باشی، حتماً کلمه «اجایل» رو هم در کنارش دیدی؛ ولی باید حواست باشه که اسکرام رو با «اجایل» یکی ندونیم!
در واقع متدولوژی Scrum در کنار کانبان، XP، لین و …، یکی از انواع روش‌ها و فریم‌‍ورک‌هاییه که زیرِ چترِ مفهومِ بزرگ‌تر «اجایل» قرار دارن.
حالا اجایل/Agile یا چابک چیه؟ اجایل یک متدولوژیه که به تیم‌ها کمک می‌کنه فعالیت‌هاشون رو سریع‌تر جلو ببرن و درعین‌حال نسبت به تغییرات و چالش‌های مسیر کاملاً انعطاف‌پذیر باشند.
کلیات دو مفهوم اسکرام و اجایل رو متوجه شدی؟ عالیه. حالا بریم توی مبحث اسکرام ریزتر بشیم.
تاریخچه اسکرام
اسکرام این روزها مفهومی جاافتاده در دنیای توسعه محصول است؛ اما بد نیست ماجرای این فریمورک محبوب و کاربردی را از ابتدا آغاز کنیم.
-
1985: اولین جرقه
ریشه‌های فریمورک اسکرام به حدود چهار دهه قبل و مقاله‌ای در «هاروارد بیزینس ریویو» برمی‌گردد.
«هیروتاکا تاکه‌ئوچی» و «ایکوجیرو نوناکا» که به‌عنوان پدربزرگان متدولوژی اسکرام شناخته می‌شوند در مقاله‌ای تحت عنوان «زمین بازیِ جدید توسعه محصول»، تیم‌های توسعه محصول را به تیم‌های راگبی تشبیه کردند.
آنها این‌طور استدلال کردند که اعضای تیم توسعه‌دهنده محصول نیز درست مانند بازیکنان تیم‌های راگبی، مسئولیت‌های متفاوتی را به عهده می‌گیرند و سرعت، انعطاف‌پذیری و وفق‌پذیری با شرایط باید از ویژگی‌های اصلی آنها باشد.
-
1993: تولد واژه اسکرام در فرهنگ توسعه محصول
اصطلاح اسکرام به‌عنوان چارچوبی برای پیشبرد پروژه‌ها برای اولین بار توسط «جف ساترلند»، مهندس نرم‌افزار شرکت «ایسل» به کار گرفته شد.
ساترلند در تلاش برای پیاده‌سازی روشی بود که تصمیم‌گیری‌ها برای مدیریت و پیشبرد پروژه، به‌جای «پیش‌بینی و احتمال» بر اساس «شواهد، داده‌ها و تجارب عینی» صورت بگیرد.
-
1995: اسکرام وارد می‌شود
جف ساترلند به همراه «کن شوابر» در مقاله‌ای مشترک با عنوان «فرایند پیشبرد اسکرام» این چارچوب را به طور رسمی به جامعه توسعه‌دهندگان نرم‌افزار معرفی کردند.
مفاهیم اساسی ارائه شده در آن مقاله همچنان به‌عنوان پایه‌های اصلی این فریمورک شناخته و به کار گرفته می‌شوند.
-
2001: مانیفست اجایل
مانیفست اجایل - که بالاتر به آن اشاره کردیم - توسط 17 مهندس نرم‌افزار از جمله ساترلند و شوابر نوشته و منتشر شد.
هماهنگی کم‌نظیر اصول اسکرام با رویکرد مدیریت اجایل، آن را فوراً به محبوب‌ترین فریمورک در متدولوژی اجایل بدل کرد.
-
2002: کتاب کن شوابر و مایک بیدل
یک سال بعد، شوابر و «مایک بیدل» با انتشار کتاب «توسعه اجایل محصول با اسکرام»، جایگاه این چارچوب را در دنیا تثبیت کردند.
این کتاب که به محبوبیت هرچه بیشتر اسکرام منجر شد، مثال‌های متعددی از پروژه‌های واقعی و مطالعه‌های موردی را شامل می‌شد.
-
2009: تکامل اسکرام
ساترلند و شوابر هفت سال بعد راهنمای جامعی برای چارچوب اسکرام منتشر کردند که در آن «نقش‌ها» و «رویدادها» - که جلوتر به آنها خواهیم پرداخت - در چارچوب اسکرام به شکلی شفاف توضیح داده شدند.
در طی یک دهه و نیم اخیر، روش اسکرام هرچه بیشتر به تکامل رسید تا جایی که امروزه علاوه بر حوزه توسعه نرم‌افزار در دیگر صنایع نیز مورداستفاده قرار می‌گیرد و کمتر نقطه‌ای در دنیا هست که این چارچوبِ مدیریتِ پروژه توسط تیم‌ها به کار گرفته نشود.
اسکرام vs مدل آبشار
مقایسه مدل اسکرام با روش‌های قدیمی‌تر می‌تواند به درک بهتر آن کمک کند. در مدل‌های سنتی‌تر مثل مدل آبشار یا Waterfall، وظایف و روند انجام کار به شکل خطی یا Linear تعیین می‌شد.
بزرگ‌ترین ایراد این مدل و دیگر روش‌های سنتی، عدم انعطاف‌پذیری آنهاست. مسئله‌ای که در تمایزی روشن با ذهنیت اجایل یا چابک قرار دارد.
در مدل آبشار، ذی‌نفعان، تیم توسعه، مخاطبان و کاربران بالقوه محصول تنها زمانی می‌توانستند محصول نهایی را ببینند و از آن استفاده کنند که دیگر فرصتی برای اصلاح و بهبود آن وجود نداشت و کار از کار گذشته بود.
در فریم ورک اسکرام اما فرایند توسعه محصول در چرخه‌های زمانی و کاری مشخص پیش می‌رود؛ در پایان هر چرخه - یا آن‌طور که جلوتر یاد می‌گیریم هر «اسپرینت» - ذی‌نفعان و کاربران بالقوه، نسبت به نرم‌افزار بازخورد داده و تیم توسعه رویکرد خود را باتوجه‌به این بازخوردها تنظیم می‌کند.
اسکرام به دنبال چیست؟
اسکرام روشی است که به تیم‌ها اجازه می‌دهد محصول خود را در گام‌های کوچک و قابل‌مدیریت توسعه دهند. اسکرام با شکستن پروژه به تکه‌های کوتاه که به آن اسپرینت می‌گویند، توانایی پیشبرد سریع امور را به اعضای یک تیم هدیه می‌کند.
به‌جای برنامه‌ریزی یکباره، انجام یکباره و تحویل یکباره یک پروژه بزرگ، اسکرام پیشرفت‌های کوچک اما پیوسته را ارج می‌نهد! اسکرام ریسک‌ها را کم می‌کند، هزینه اشتباهات را کاهش می‌دهد و اطمینان حاصل می‌کند محصول نهایی واقعاً پاسخگوی نیازهای کاربر باشد.
اسکرام در هسته مرکزی خود، فلسفه «هوشمندانه‌تر کار کن، نه سخت‌تر» را ترویج می‌کند و می‌توان آن را در سه عبارت خلاصه کرد: ارائه سریع ارزش، یادگیری از بازخوردها، پیشرفت پیوسته.
فریمورک اسکرام بر اساس راهنمای مبدعان و مروجان آن یعنی جف ساترلند و کن شوابر شامل پنج جنبه/لایه/ساحت است: نقش‌ها، رویدادها، ابزارها، اصول و ارزش‌ها.
یک نفس عمیق بکشید و آماده بخش جذاب ماجرا شوید چون می‌خواهیم این پنج بخش را یک به یک تشریح کنیم.
نقش‌های اسکرام/Scrum Roles
اسکرام به‌طورکلی دارای سه نقش اصلی است: مالک محصول، اسکرام مستر، توسعه‌دهندگان محصول.
-
مالک محصول/Product Owner
مالک محصول یا PO تصمیم‌گیرنده اصلی درباره محصول است. تعیین چشم‌انداز و اهداف محصول، اولویت‌بندی بک‌لاگ محصول بر اساس ارزش‌های تجاری، تعیین نیازمندی‌های تیم، تعامل با و گزارش‌دهی به ذی‌نفعان و اطمینان حاصل‌کردن از بازگشت سرمایه از جمله وظایف اصلی مالک محصول است.
-
اسکرام مستر/Scrum Master
مربی و هدایت‌کننده تیم؛ اطمینان حاصل‌کردن از دنبال‌شدن گام‌های فریمورک، تسهیلگری جلسات اسکرام، برطرف‌کردن موانع و چالش‌های تیم، آموزش ذهنیت اجایل، به‌وجودآوردن فضای همکاری و اطمینان حاصل‌کردن از پیشرفت کار و به سرانجام رسیدن اسپرینت‌ها.
-
توسعه‌دهندگان محصول
همه افرادی در طراحی، توسعه و ساخت محصول دخیل‌اند. تیم توسعه محصول یا توسعه‌دهندگان باتوجه‌به بزرگی و نیازهای پروژه می‌تواند شامل برنامه‌نویسان، مهندسین کنترل کیفیت یا تست نرم‌افزار، مهندسین دواپس، گروه تولیدکنندگان محتوا، طراحان گرافیک، طراح و محقق UX/UI و تحلیلگر کسب‌وکار باشد.
رویدادهای اسکرام/Scrum Events
اسکرام به‌طورکلی شامل مجموعه‌ای از پروژه‌های خرد (اسپرینت‌ها)، جلسات اسپرینت و جلسات روزانه است که به پنج رویداد یا فعالیت اصلی تقسیم می‌شوند:
برنامه‌ریزی اسپرینت، جلسات استندآپ روزانه، اجرای اسپرینت، بازبینی اسپرینت، اسپرینت بازنگری.
-
برنامه‌ریزی اسپرینت / Sprint Planning:
هر اسپرینت با جلسه «برنامه‌ریزی اسپرینت» آغاز می‌شود:
-
در این جلسه، مالک محصول، اولویت‌های پروژه را از میان تسک‌های بک‌لاگ محصول تعیین می‌کند.
-
اعضای تیم، بک‌لاگ اسپرینت - یعنی تسک‌های موردنیاز برای به سرانجام رساندن اسپرینت - را مشخص می‌کنند.
-
اعضای تیم، تسک‌هایی را که می‌توانند در طول دوره اسپرینت - که معمولاً بین دو تا چهار هفته است - به انجام برسانند، بر عهده می‌گیرند.
-
مالک محصول و اعضای تیم، هدف اسپرینت یا همان خروجی اصلی اسپرینت را مشخص و بر روی آن توافق می‌کنند.
وظایف تعیین‌شده با هم‌فکری و مشارکت اعضای تیم و با نظارت مالک محصول و البته اسکرام مستر صورت می‌گیرد. این برنامه‌ریزی جمعی باعث می‌شود تا اعضای تیم توسعه‌دهنده محصول درک بهتری از فرایند کار و مسئولیت‌های خود داشته باشند.
-
جلسات استندآپ یا اسکرام روزانه / Daily Stand-Ups or Daily Scrums:
اسکرام مستر وارد می‌شود؛ هدف این جلسات حفظ هماهنگی و شفافیت بین اعضای تیم و شناسایی چالش‌هاست:
-
جلسات استندآپ معمولاً در نشست‌های 15 دقیقه‌ای برگزار می‌شوند.
-
هر عضو تیم به سه سؤال پاسخ می‌دهد:
1. دیروز چه کردم؟
2. امروز چه می‌کنم؟
3. چه چالش‌هایی دارم؟
در این جلسات، اسکرام مستر به‌عنوان تسهیلگر بر بهره‌وری فعالیت‌های اعضای تیم و منظم پیش رفتن امور تمرکز دارد.
-
اجرای اسپرینت / Sprint Execution:
اعضای تیم توسعه محصول بر روی تسک‌های خود متمرکز می‌شوند.
فرایند پیشرفت کار باید همراه با تعامل و شفافیت کامل در بین اعضای تیم باشد.
اعضای تیم باید بتوانند به‌صورت خود سازمان‌یافته شده پیش بروند.
-
جلسه مرور اسپرینت / Sprint Review:
در پایان هر اسپرینت، جلسه مرور و بازبینی برگزار می‌شود؛ در این جلسه:
-
اعضای تیم گزارش پیشرفت کار را ارائه می‌کنند؛
-
مالک محصول از ذی‌نفعان بازخورد می‌گیرد؛
-
ایده‌های نو و اصلاحات احتمالی به فهرست امور بک‌لاگ محصول اضافه می‌شوند.
-
اسپرینت بازنگری / Retrospective Sprint:
این جلسه نیز در پایان هر اسپرینت و بین تیم توسعه محصول و اسکرام مستر برگزار می‌شود؛ مواردی که در این جلسه بررسی می‌شوند عبارت‌اند از:
-
بررسی و شناسایی آنچه خوب پیش رفت و آنچه خوب پیش نرفت
-
شناسایی فعالیت‌ها و امور قابل‌بهبود
جلسات اسپرینت گذشته‌نگری به‌منظور پرورش رویکردی آینده‌نگر و یادگیری از اشتباهات و جلوگیری از تکرار آنها در اسپرینت‌های بعدی بسیار کلیدی است.
باید توجه داشت که عمده این تعاریف بسیار کلی هستند و جزئیات متعدد و متفاوتی می‌تواند به هر رویداد اضافه شود.
ابزارهای اسکرام / Scrum Artifacts
اسکرام دارای سه ابزار کلی است: بک‌لاگ محصول، بک‌لاگ اسپرینت و انجام‌شده‌ها.
آنچه در انگلیسی تحت نام «مصنوعات اسکرام/Scrum Artifacts» شناخته می‌شود - و ما در اجیلیتی آن را ابزار می‌نامیم - به مجموعه فهرست‌هایی از اطلاعات می‌گویند که تعیین‌کننده اولویت‌های پیشرفت پروژه‌اند.
-
بک‌لاگ محصول یا انباشت محصول / Product Backlog:
بک‌لاگ محصول نقش فهرست کارهایی است که باید انجام شوند. یک بک‌لاگ توسط صاحب محصول اولویت‌بندی شده و شامل نقشه راه، نیازمندی‌های تیم و هدف محصول است.
بک‌لاگ محصول با توجه روند پیشرفت پروژه و در پایان هر اسپرینت می‌تواند از طرف ذی‌نفعان یا تیم توسعه‌دهندگان به‌روزرسانی شود.
-
بک‌لاگ اسپرینت یا انباشت اسپرینت / Sprint Backlog:
بک‌لاگ اسپرینت در زمان برنامه ریزی اسپرینت شکل می‌گیرد؛ تیم توسعه‌دهنده محصول در ابتدای هر اسپرینت وظایفی را از فهرست بک لاگ محصول انتخاب کرده و مسئولیت آن را بر عهده گرفته و آن را به بک‌لاگ اسپرینت اضافه می‌کنند.
این موارد معمولاً مهم‌ترین وظایفی هستند که هر فرد باید در طول هر اسپرینت به سرانجام برساند؛ در آغاز هر اسپرینت و با به‌روزرسانی مجدد بک‌لاگ محصول، شرح وظایف هر فرد نیز می‌تواند دستخوش تغییر شود.
-
انجام‌شده‌ها یا پیشرفت کار / Increments:
رهرو آن است که آهسته و پیوسته رود؛ فهرست کارهای انجام‌شده یا پیشرفت کار به مواردی اشاره دارد که می‌توان آنها را به‌عنوان یک گام روبه‌جلوی واقعی و شفاف در مسیر توسعه محصول و هدف نهایی در نظر گرفت.
باید توجه داشت که در هر اسپرینت باید «کار انجام‌شده یا تمام‌شده یا Done»، باید دارای تعریف شفاف و مشخصی باشد که معمولاً به کمک اسکرام مستر مشخص می‌شود.
«تعریف انجام‌شده یا Definition of Done» که به‌اختصار DOD نامیده می‌شود، به تیم شما کمک می‌کند بدانند چه زمانی یک تسک واقعاً به پایان رسیده است.
داشتن تعریفی شفاف و دقیق از DOD بسیار کلیدی است؛ زیرا تعاریف نادرست و غیرشفاف می‌تواند آسیب‌های جدی به روند پیشرفت توسعه محصول وارد کند.
اصول اسکرام / Scrum Principles:
اسکرام بر سه اصل یا ستون استوار شده است: شفافیت، بازرسی، وفق‌پذیری. این سه اصل تضمین می‌کنند که محصولی باارزش و باکیفیت تولید شود؛ اما چطور؟
-
شفافیت/Transparency:
تمامی اعضای تیم و ذی‌نفعان پروژه باید درکی روشن و مشترک از کار، اهداف و پیشرفت داشته باشند. تمام اطلاعات تعیین‌کننده مانند پیشرفت، چالش‌ها و استانداردهای کیفی باید برای تک‌تک اعضای تیم قابل‌درک و آشکار باشند.
چرا شفافیت مهم است؟
-
بین اعضای تیم اعتماد می‌سازد.
-
اعضای تیم را هماهنگ می‌کند.
-
بازرسی/Inspection:
اعضای تیم باید به‌صورت مستمر پیشرفت کار، کیفیت کار و سلامت کلی پروژه را چک یا به عبارتی «بازرسی» کنند؛ این کار باعث پایین آمدن ریسک می‌شود. این بازرسی‌ها در ایستگاه‌های مشخصی مانند اسکرام‌های روزانه و جلسات بازبینی رخ می‌دهد.
چرا بازرسی مهم است؟
-
چالش‌ها را به‌موقع شناسایی می‌کند.
-
ریسک‌ها و هزینه‌ها را پایین می‌آورد.
-
وفق‌پذیری/Adaptation:
بر اساس آنچه اعضای تیم شما در روند «بازرسی‌ها» یاد می‌گیرند، برنامه‌ها، فرایندها و نحوه کار خود را اصلاح و بهینه می‌کنند. یک تیم اسکرام باید آن‌قدر منعطف باشد که بتواند نیازها و دغدغه‌های تازه را به‌درستی مدیریت کند.
چرا وفق‌پذیری مهم است؟
-
ارزشمندبودن محصول را تضمین می‌کند.
-
روند روبه‌جلوی تیم را تضمین می‌کند.
بررسی ارزش‌های اسکرام / Scrum Values:
در نسخه دوم «راهنمای اسکرام» که کن شوابر و جف ساترلند در سال 2016 منتشر کردند، پنج ارزش به‌عنوان پایه‌های موفقیت اسکرام معرفی شد:
شجاعت، تمرکز، تعهد، احترام و شفافیت.
شوابر و ساترلند در این به‌روزرسانی تأکید بسیاری بر جنبه «انسانی» چارچوب اسکرام داشتند.
این ارزش‌ها بیش از آنکه قواعدی اجراکردنی باشند، ذهنیت و رویکرد تیم را شکل می‌دهند و تعیین‌کننده رفتار اعضای تیم هستند.
این ارزش‌ها به‌ویژه در شرایطی که آزمون‌وخطا بخشی اساسی از پیشرفت فرایند کار هستند، اهمیتی دوچندان پیدا می‌کنند.
اما این ارزش‌ها در عمل چطور نمود می‌یابند:
-
شجاعت/Courage:
گفتیم که اسکرام به تیم‌ها کمک می‌کند کارها را سریع‌تر پیش ببرند؛ از طرفی اما در چارچوب اسکرام، مسیر پیش رو کاملاً شفاف نیست و در اکثر مواقع باید نحوه انجام کارها را به اعضای تیم خود بسپارید.
بدیهی است اعضای چنین تیمی باید جسارت این داشته باشند که ابتکار عمل را به دست گرفته و با چالش‌ها رودررو شوند. حفظ قواعد بازی در زمان فشار و بار کاری بالا نیازمند افراد جسور و قوی است.
-
تمرکز/Focus:
اعضای تیم در هر بازه زمانی فقط روی یک یا چند هدف مشخص تمرکز می‌کنند؛ مواردی مانند هدف اسپرینت یا آیتم‌هایی از بک‌لاگ محصول. تمرکز مانع حواس‌پرتی اعضای تیم و هرز رفتن انرژی و هزینه‌ها خواهد شد.
-
تعهد/Commitment:
اعضای تیم شما باید به اهداف هر اسپرینت، محصول نهایی و خود سازمان متعهد باشند.
این تعهد فقط به انجام تسک‌ها محدود نمی‌شود؛ بلکه تیم توسعه‌دهنده باید عمیقاً با محصول عجین شده و به دنبال ارائه یک خروجی ارزش‌آفرین برای کاربران باشند.
تعهد با خود مسئولیت‌پذیری و پاسخگویی می‌آورد و اعضای تیم را به ارائه خروجی‌های ارزشمند هدایت می‌کند.
-
احترام/Respect:
اعضای تیم شما باید بتوانند به ایده‌ها و مهارت‌های یکدیگر احترام بگذارند.
همه اعضا باید به ارزشی که هر عضو دیگر به تیم و پروژه اضافه می‌کند کاملاً واقف باشند.
این فاکتور در ایجاد فضای همدلی و همکاری بین اعضای تیم بسیار حیاتی است.
-
صراحت/Openness:
اعضای تیم باید در فضایی شفاف و صادق کار کنند.
چالش‌ها، پیشرفت‌ها و بازخوردها باید بدون ترس و نگرانی و به شکلی صریح بین افراد مطرح شوند.
این ارزش به ایجاد اعتماد در بین اعضای تیم منجر می‌شود.
مزایا و معایب متدولوژی اسکرام
چارچوب اسکرام دارای ویژگی‌هایی است که آن را بدل به ساختاری ایده آل برای پیشبرد پروژه‌های توسعه نرم‌افزار بدل کرده است. مزایای مهم اسکرام که آن را به روشی محبوب در دنیا بدل کرده را می‌توان در موارد زیر خلاصه کرد:
-
انعطاف‌پذیری بالا
-
تمرکز بر نیازهای کاربر
-
روندی پیوسته روبه‌جلو
-
تعامل و همکاری باکیفیت
-
ارائه سریع خروجی ارزشمند
اما… هنرش جمله بگفتی، عیب وی نیز بگو؛ آیا روش Scrum بی‌عیب‌ونقص است؟ مسلماً خیر. اجازه بدهید برخی معایب آن را نیز بررسی کنیم.
-
نیازمند تغییر ذهنیت است:
اعضای هر تیم باید بتوانند ویژگی‌هایی مثل انعطاف‌پذیری و خودسازماندهی را در خود پرورش دهند. چنین امری برای نیروهایی که به روندهای خشک و چارچوب‌بندی شده عادت دارد، دشوار است.
-
همواره همراه با عدم اطمینان است:
ازآنجایی‌که اسکرام راه را برای نقد و اصلاح و تغییر باز می‌گذارد، نمی‌توان تاریخ دقیقی را برای پایان پروژه‌های آن تضمین کرد. کنارآمدن با این فرایند برای ذی‌نفعان که به زمان‌بندی‌های دقیق عادت دارند، دشوار است.
-
وابستگی زیادی به همکاری تیمی دارد:
اسکرام وابستگی بسیار بالایی به کار تیمی و خودمدیریتی دارد. تیمی که اعضای دیسیپلین و مهارت ارتباطی ضعیفی داشته باشند، با فریمورک اسکرام راه به جایی نخواهند برد.
-
جلسات متعدد آن زمان‌برند:
جلسه در ابتدا، جلسه در انتها و ده‌ها ریزجلسه در طول هر اسپرینت زمان زیادی از اعضای تیم می‌گیرد. اگر یک اسکرام‌مستر کاربلد بالای سر تیم نباشد، باید قید «چابکی» را زد.
-
مناسب «پروژه‌های کوچک» یا «تیم‌های بزرگ» نیست:
اسکرام برای پروژه‌های کوچک زیادی جامع است؛ به‌کارگیری رویکرد سرراست‌تر برای پروژه‌های کوچک می‌تواند بسیار کارآمدتر باشد.
از طرف دیگر اگر تیم‌های توسعه تعداد بالایی عضو داشته باشند نیز در مدیریت، برقراری ارتباط و هماهنگی ممکن است با چالش‌های متعدد روبه‌رو شوند.
جمع‌بندی
اسکرام، فریم‌‍ورکی است که ذهنیت و متدولوژی اجایل را در بهترین و بهینه‌ترین شکل آن ارائه می‌کند.
فریمورک اسکرام به‌آسانی قابل‌درک است؛ اما اجرای نیازمند پیش‌نیازهای متعدد و تعهد بسیار بالاست؛ اما تیم‌هایی که موفق به اجرای درست آن می‌شوند، موفقیت را در مشت خود دارند.
هنوز هم سؤال داری یا بخشی از مطلب بود که به‌درستی برایت جا نیفتاد؟ همین حالا به کامیونیتی اجایل سر بزن و سؤالت رو بپرس…