نگران نیستیم! در حاشیه انتشار کاریکاتور منتسب به خبرگزاری تسنیم

پوریا احمدی

۱۳۹۶/۱۰/۲۳

CBO
b

مدلسازی با Raymarching و میادین فاصله در یونیتی

سید مرتضی کمالی

۱۳۹۶/۱۱/۲۷

راهنمای ارسال مقالات برای گیمولوژی

علیرضا محمدی

۱۳۹۷/۰۱/۲۷

سردبیر
b

شیدر نویسی در یونیتی (بخش دوم)

سید مرتضی کمالی

۱۳۹۶/۰۸/۱۳

چالش‌های بازگشت بازیکنان به بازی

سمیرا دولت‌آبادی

۱۳۹۶/۰۸/۰۲

عضو تحریریه
b

شیدرنویسی در یونیتی (بخش اول)

سید مرتضی کمالی

۱۳۹۶/۰۷/۲۶

مارکتینگ بازی: طراحی برنامه

سمیرا دولت‌آبادی

۱۳۹۶/۰۷/۲۰

عضو تحریریه
b

باز‌ی سازان بزرگ چطور شما را گول می‌زنند؟

فرناز حقیقت

۱۳۹۶/۰۶/۱۶

روابط عمومی
b

قابلیت‌های آنلاین در بازی‌های تک نفره

رهام سجادی

۱۳۹۶/۰۷/۱۵

عضو تحریریه
b

فرآیند های چابک بازی سازی Agile Game Development Methods

در ابتدای پیدایش بازی‌های رایانه ای، شخص به‌ تنهایی بر روی یک بازی کار می‌کرد و نیازی به "متدولوژی ساخت" نداشت. یک بازی را می شد طی چند ماه تولید کرد. هر چه سخت ‌افزار های بازی ‌های رایانه ای، پیشرفت کرد، میزان انرژی، کار و سرمایه برای ساخت بازی‌ها بیشتر می ‌شد به همین دلیل دیگر ساخت بازی برای کنسول‌های جدید تر، یک نفره انجام نمی  ‌شد و گروه‌ها از 3 یا 4 نفر بیشتر شدند و شرکت های بازی سازی تاسیس شد.

در آن زمان، متدولوژی ‌ها به کمک شرکت‌ها آمدند تا درصد ریسک کارها را کمتر کنند. در ابتدا شرکت‌ها از روش‌های کلاسیک (RUP) استفاده می‌کردند اما در سال 2001 گروهی از کارشناسان گرد هم آمدند و گردهمایی اجایل را تشکیل دادند. آن‌ها از طریق این روش به ارزش‌های زیر رسیدند:

·        افراد و تعاملات بالاتر از فرآیندها و ابزارها

·        نرم‌افزار کارکننده بالاتر از مستندات جامع

·        مشارکت مشتری در انجام کار بالاتر از قرارداد کار

·        پاسخگویی به تغییرات بالاتر از پیروی یک طرح

باوجود اینکه موارد سمت چپ نیز ارزشمند هستند ولی آن‌ها برای موارد سمت راست ارزش بیشتری قائل بودند.

 

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

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

1-     بالاترین اولویت ما رضایت مشتری از طریق تحویل به‌ موقع و مداوم نرم‌افزار ارزشمند می‌باشد.

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

3-     تحویل نرم‌افزار کارکننده غالباً از چند هفته تا چند ماه یک‌بار انجام می‌شود که زمان‌بندی کوتاه ‌تر ترجیح داده می‌شود.

4-     تاجران و توسعه‌دهندگان باید هر روزه در طول پروژه با هم کار کنند.

5-     پروژه‌ها را بر روی افراد باانگیزه بنا کنید. محیط لازم را به آن‌ها بدهید و از نیازهای آن‌ها پشتیبانی نمایید. باید به آن ها اعتماد کنید.

6-    کارآمد ترین و مؤثر ترین روش برای انتقال و رساندن اطلاعات به تیم توسعه، گفتگوی  رو در رو می‌باشد.

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

8-    حامیان مالی، توسعه‌دهندگان و کاربران باید قادر به حفظ سرعت پیشرفت ثابتی براى يک مدت نامحدود باشند.

9-    توجه مداوم به برتری فنی و طراحی خوب باعث افزایش چابکی می‌شود.

10-   اصل سادگی ضروری می‌باشد.

11-    بهترین معماری‌ها , نیازمندی‌ها و طراحی‌ها از تیم‌های خود سازمانده پدیدآور می‌شود.

12-    در فواصل منظم، تیم بر چگونگی مؤثر تر شدن فکر می کند و سپس تیم رفتار خود را بر اساس بازتاب این تفکر تنظیم و هم سو می‌نماید . مدل مترو

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

 

SCRUM

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

 

رویه‌ی اصلی اسکرام

 

·       شناسایی مشخصات محصول (تشکیل Product Backlog)

·       اولویت‌بندی و تقسیم مشخصات به چند دوره (Sprint)

·       پیاده‌سازی دوره‌ی اول در بازه‌ی مشخص (2 هفته تا 3 ماه)

·       تست و آماده نمودن اولین محصول خروجی و عرضه آن

·       شروع دوره‌ی بعدی با اضافه کردن بازخوردهای دوره قبل

·         ادامه‌ی رویه تا پایان تولید یا پایان عمر محصول

نقش های اسکرام 

    • مشتریان (ذینفعان) : Stakeholders
    • مالک محصول : Product Owner
    • استاد اسکرام : Scrum Master
    • تیم تولید : Development Team

جلسات اسکرام

1- جلسات ایستاده روزانه Daily Standup Meeting:

در شروع هر روز کاری در گروه های تولید بازی به سبک اسکرام جلساتی را به مدت 10 تا 15 دقیقه به صورت ایستاده برگزار می کنند که این جلسات به Stand up meeting  مشهور می باشد. در این جلسه کوتاه 3 سوال اصلی مطرح می شود :

·         دیروز چه کار انجام داده ام ؟

·         امروز چه کاری می خواهم انجام بدهم ؟

·         مشکلاتی که در سر راه دارم چه چیزهایی هستند ؟

 

2- جلسات برآورد (ابتدای Sprint)

 

بازی پوکر برنامه ریزی در ابتدای اسپرنت صورت میگیرد. کارت های این روش مثل عکس بالا می باشند که یک دست از کارت ها به هر یک از اعضای تیم اسکرام داده می شود  . شماره ها نمایانگر تعداد ساعت و علامت ( ؟ ) نمایان گر این خواهد بود که «من نظری ندارم!» و علامت «بی نهایت» نمایان گر این است که تعداد ساعت بیشتر از 21 ساعت خواهد بود. در گام نخست شما یک ویژگی را از Product Backlog انتخاب می کنید و به تیم اسکرام می گویید که ویژگی جاری، این ویژگی می باشد. بعد اعضای تیم شروع به بحث و توضیح در مورد این ویژگی می کنند. بعد از این مرحله، شما به عنوان اسکرام مستر به تیم اسکرام می گویید که چند ساعت لازم دارید تا این ویژگی را پیاده سازی، تست و آماده ارائه به مشتری نمایید. هر یک از اعضای تیم نسبت به تحلیل و ذهنیت خود یکی از کارت ها را انتخاب می کند و با شماره 3 همه کارت ها را نشان می دهند ..

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

 

3- جلسات جمع بندی (انتهای Sprint)

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

دیدگاه‌ها

پاسخ
١١
٢

آرش رسول زاده   |   ۱۳۹۵/۰۴/۱۹   |   ۲۳:۲۷

مدیریت تو تیمایی که مدیر ندارن سخته

پاسخ
١١
٠

خشایار صاحبکار   |   ۱۳۹۵/۰۴/۲۰   |   ۱۷:۲۴

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

روابط عمومی
b
١١
٠

فرناز حقیقت   |   ۱۳۹۵/۰۴/۲۳   |   ۱۸:۱۹

اره متاسفانه به دلیل محدودیت زمان بخش های کلی اجایل را گفتم که در همه جا کاربرد داشت

پاسخ
١١
٢

Mr.BigBang   |   ۱۳۹۵/۰۴/۲۰   |   ۲۲:۲۳

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

مدیر فنی
b
١١
٠

سیاوش نوروزی   |   ۱۳۹۵/۰۴/۲۰   |   ۲۲:۴۴

همانطور ک نظرات شما رو میخونیم و تایید میکنیم مقاله تحت عنوان "تست" شما رو هم خوندیم :) ممنون ک سلامت سیستم رو آزمایش کردید...

١١
١

Mr.BigBang   |   ۱۳۹۵/۰۴/۲۱   |   ۱۰:۵۶

خواهش می کنم دی:
پس من مقالمو تو چند روز آینده میفرستم براتون

روابط عمومی
b
١١
٠

فرناز حقیقت   |   ۱۳۹۵/۰۴/۲۲   |   ۱۱:۳۴

خوشحالم باعث شدم انگیزه پیدا کنید برای نوشتن یک مقاله بهتر

١٢
١

Mr.BigBang   |   ۱۳۹۵/۰۴/۲۳   |   ۱۰:۴۳

نه ربطی به شما نداره. این انگیزه رو از خیلی وقته پیش دارم ولی خب یکم اعتماد نداشتم که حل شد دی:

روابط عمومی
b
١١
٠

فرناز حقیقت   |   ۱۳۹۵/۰۴/۲۳   |   ۱۸:۴۰

خدا رو شکر پس

پاسخ
١١
٠

Mr   |   ۱۳۹۵/۰۴/۲۲   |   ۱۲:۵۹

مثله هميشه عالى.

پاسخ
١١
٠

پوریا جعفری   |   ۱۳۹۵/۰۵/۲۳   |   ۱۳:۱۰

درود بر شما
سپاس بابت نوشته خوبتون.
مدیریت یک پروژه گروهی کاری بس دشوار است و نیازمند تجربه کافی و فکر و پردازش تمامی امور میباشد.
مدیریته یک دوره همی, جدای از موضوع کار خود به تنهایی نیازمند مدیری تواناست زیرا در یک دوره همی تعدادی عضو با جنسیت های متضاد از فرهنگ های مختلف قصد تعامل با یکدیگر را دارند. پس پیش از اینکه هدف مدیریت یک پروژه باشد, باید بتوان یک دوره همی را مدیریت کرد.