بایگانی دسته: چابک

چابک

هنر تنبلی یا چطور یاد بگیریم اول کار رو انجام بدیم!

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

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

اما تو همه این رفت و آمدها و تعامل با انسانهای متفاوت تجربه خیلی متفاوتی رو همین هفته گذشته شاهد بودم، تو دوره فشرده آموزشی که برای یک شرکت تولید نرم افزار داشتم، شاهد این بودم که پروژه های متوسط رو به بزرگی را با رویکرد بزن در رو به جلو سوق داده بودن و بدون اینکه فکر کنن میتونن یک شالوده(framework) مشترک بین چند ده پروژه خودشون داشته باشن و دقیقاً از کانسپتهایی استفاده میکنند که Robert C. Martin در کتاب Clean Code خودش بعضاً اونها رو به توسعه گرها توصیه میکنه مثل استفاده از امکانات IDE (به دلیل رعایت اخلاق حرفه ایی قصد شرح تکنیکهاشون رو ندارم).

جالبه همین شرکت با همین نگاه پیش پا افتاده به مهندسی نرم افزار یا بهتره بگیم تولید نرم افزار موفق به جذب بالای هزار مشتری برای خودش در طول زمانی کمتر از ۵ سال شده و این دقیقاً اون چیزیه که Jeff Atwood هم به اون اشاره داره، یعنی هنر انجام یک کار و این یعنی اثبات حرف Robert Martin در عمل یعنی استفاده از ابزار موجود برای پیشبرد کار.

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

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

نتیجه اخلاقی

با توجه به تعداد شرکتهایی که از نرم افزار شرکت مذکور در حال استفاده هستند به جدّ میتونم به این نتیجه برسم که OOP یا FP فاکتورهای مناسبی برای استاندارد کد زدن نیستن، اگر به فاکتور رضایت مشتری توجه بیشتری بکنیم شاید به این نتیجه برسیم که مشتری راضی به اسپاگتی کدی هست که کار کنه و نه کلاسهای پیچیده ایی که هر روز یک باگ جدید در اونها کشف بشه!

من به انجام اولیه کار به هر روشی، میگم تنبلی و باهوش بازی درنیاوردن بابت انجام کار، که این خودش یه هنره!

سوالات بی جواب

آیا میتوان آینده ایی ورای OOP ،FP و یا MDA برای صنعت نرم افزار متصور بود که در اون مسائل حول محور دامنه بیزنس حل بشوند و نه حول محور مهندسی نرم افزار؟(DDD هم براساس OOP هست آیا رویکرد جدیدتری وجود داره؟)

آیا ۴GL مبحثی نبود که صنعت نرم افزار میبایست طی میکرد و آنرا به حد اعلای خود میرساند؟

آبا فریم ورکهایی مانند RoR مسکنهای موضعی برای درد مشتری مداری هستند؟ و وقت آنها هم به سر خواهد آمد؟

————————– آپدیت————————–

آفتاب آمد دلیل آفتاب، همین الان مصاحبه STLPORT با A. Stepanov مخترع STL رو خوندم که اتفاقاً ایشون با اینکه خودش STL رو برروی C plus plus پیاده کرده خودش مخالف OOP هست و از نظر درستی اون رو رد کرده.

http://www.stlport.org/resources/StepanovUSA.html

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

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

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

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

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

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

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

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

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

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

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

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

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

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