چگونه از رویه توسعه اسکرام در بازی‌سازی استفاده کنیم؟

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

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

Agile چیست؟

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

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

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

بازی ساز‌های مستقل چگونه می‌توانند از Agile استفاده کنند؟

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

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

مفاهیم و دیزاین می‌تواند در تمامی مراحل توسعه تغییر کند ( حتی اگر در فاز پساتولید باشیم). البته اگر این تغییرات ددلاین نهایی را زیادی تغییر ندهد.

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

• ساده: می‌توانیم مشکل را با یک برنامه‌ریزی قبلی حل کنیم.
• بغرنج (Complicated): می‌توانیم مشکل را به مراحل ساده‌تر تقسیم کنیم.
• پیچیده (Complex): می‌توانیم از یک روش تجربی برای حل مشکل استفاده کنیم و بررسی کنیم که آیا در راه درست قرار داریم یا نه.
• هرج‌و‌مرج: یک آشوب کامل.

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

SCRUM چیست؟

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

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

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

نقش‌ها و وظایف در اسکرام

یک پروژه اسکرام معمولا شامل ۳ نقش یا مسئولیت‌پذیری است.

صاحب محصول (Product Owner)

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

مدیر اسکرام ( Scrum Master)

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

تیم توسعه

• معمولا از ۵ تا ۱۰ نفر تشکیل می‌شود.
• بک‌لاگ اسپرینت را انتخاب می‌کند.
• حق انجام هر کاری را در حوزه‌ی پروژه دارد تا به هدف اسپرینت برسد.
• کار خود را ساختاربندی می‌کند.
• نتایج کار را به صورت دمو به صاحب محصول ارائه می‌دهد.

جلسات در اسکرام

یکی از قسمت‌های مهم در رویه Agile و اسکرام جلسات هستند.

جلسه برنامه‌ریزی اسپرینت

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

اسکرام روزانه

• سه سوال در جلسه روزانه پرسیده می‌شود: دیروز چه کاری انجام دادید؟ امروز چه کاری انجام می‌دهید؟ و چه کار‌هایی باید برای آن انجام دهید؟
• این جلسه بیشتر برای هماهنگی و تعهد بین اعضای تیم توسعه است و یک جلسه مدیریتی نیست.

بررسی اسپرینت

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

نگاه به اسپرینت گذشته

• تمرکز بر پیشرفت دنباله‌دار.
• به اسپرینت قبلی نگاه کنید و این سوالات را بپرسید: چه چیزی به خوبی پیش رفت؟ چه چیزی را باید بهتر کنیم؟ موانع چه بودند؟

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