بایگانی برچسب: s

کمدی به نام اسکرام در صنعت نرم افزار ایران

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

راغب میشم بیشتر بدونم که دقیقاً چطور اسکرام رو پیاده کردن ازشون میپرسم آیا اسکرام مستر دارین؟

میگن آره آقا/خانم فلانی اسکرام مسترمون هست. ،خب ایشون دقیقاً چکار میکنن؟

جوابها اکثراً با جملاتی اینچنینی به پایان میرسه که اسکرام مستر خودشون مدیرعامل شرکت هستند یا یکی از اعضای هیئت مدیره هستند که البته سرشون خیلی شلوغه و بیشتر کارهای مدیریتی رو انجام میدن!

در مورد نحوه کار کرد اسکرام در شرکت میپرسم و اینکه چطوری اون رو پیاده کردن میپرسم از اینکه آیا لیست کارهای هفتگی یا دوهفتگیشون رو جایی نگه میدارن آیا کارهای براساس هزینه انها اولیت بندی میشوند؟ آیا جلسات روزانه برگزار میکنید؟

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

این نوع برخوردها عموماً محدود به وسعت جغرافیایی ایران نمیشه و میشه از این دست مدیریتهای سلیقه ایی ولی با اسم جدید را در تمام دنیا مشاهده کرد، این نوع برخورد در اسکرام معروف است به  scrum-but بدین معنا که ما در حال اجرا اسکرام هستیم اما کار خودمون رو میکنیم. لزوماً اینکه گروهی یا شرکتی کارخود را میکند و شیوه مدیریت خود را دارد بد نیست ولی اینکه بخواهیم کارهای قدیمی و بعضاً و غلط خود را به متدلوژیهای جدید نسبت بدهیم و بعد انتظار داشته باشیم با پیاده سازی روشهای قدیم ولی با اسم جدید به نتایج جدیدتر و مطلوبتری برسیم کمی دور از منطق و انصاف هست!

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

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

اسکرام به دلیل نگاه سطح بالایی و نسبتاً ناقصی که به مدیریت پروژه داره نمیتونه بعنوان یک متدلوژی کامل و در سطح کاربردی مطرح بشه و بیشتر میتونه در حد یکسری اصول و قرارداد اولیه در یک شرکت و یا گروه بر اون حساب بازکرد.

اما یک تیم توسعه واقعاً نیاز داره که بدونه باید چه کاری انجام بده، نیاز داره که بدونه از چه استراتژی برای تست، از چه استراتژی برای ریلیز و چه از استراتژی برای نگهداری و تلفیق ادامه دار باید استفاده کنه که هیچکدوم از اینها توی اسکرام جواب داده نمیشه.

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

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