بایگانی

Posts Tagged ‘توسعه نرم افزار’

یه ذره دیگه

اکتبر 14, 2011 بیان دیدگاه

https://i1.wp.com/blog.irscrum.com/wp-content/uploads/2011/10/father-waking-up_42-16110224-2.jpgزمانی که مدرسه می رفتیم و صبح زود برای کسب علم از خواب ناز بیدارمون می کردن همیشه از دیالوگ های مشهور «فقط 5 دقیقه دیگه یا یه ذره دیگه یا …»  استفاده می کردیم ، حالا در صنعت توسعه نرم افزار هم بعضا مدیران یا ارایه دهندگان محصولات با چنین مشکلی مواجه می شوند و آنها هم احتمالا به مشتری می گویند «حالا این مورد رو هم اضافه کنیم یا حالا این رو هم درست کنیم و…» .

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

 «استفاده» مانند اکسیژن برای ایده ها می باشد. در حقیقت شما نخواهید دانست که یک قابلیت و امکان ضروری می باشد تا زمانی که ضرورت آن ثابت شود و چه زمانی بهتر از استفاده کاربران.

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

یاشیاسیز

Advertisements

همه چیز Timebox هست

آوریل 20, 2011 ۱ دیدگاه

https://i1.wp.com/blog.irscrum.com/wp-content/uploads/2011/04/time-box-scrum-285x300.jpgامیر مهرانی در وبلاگ خود مطلبی با عنوان ‹مدیریت زمان با تکنیک Time Boxing ‹ نوشته است که بی ربط با مطالب ارائه شده درباره اسکرام و Agile نیست. همانطور که در مطالب و نوشته های در مورد اسکرام خوانده اید تمام جلسات و رویداد ها در اسکرام Time Boxed می باشند به عبارتی هر جلسه و یا رویداد مانند یک اسپرینت قبل از شروع زمان یا طول آن تعیین می شود سپس رویداد مورد نظر به اندازه در نظر گرفته شده اجرا می شود.

تمام نکات مثبت اشاره شده در نوشته یاد شده در رابطه با Time Boxing در اسکرام نیز صدق می کند. برای مثال در نوشته می خوانیم :

Time Boxing به شما کمک می‌کنه تا بتونید برای یک کار محدوده های زمانی کوتاه تعریف کنید. مثلا برای ۳۰ دقیقه روی کار مشخصی متمرکز شوید و آن را به بهترین نحو ممکن انجام بدهید.

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

https://i1.wp.com/blog.irscrum.com/wp-content/uploads/2011/04/Il_pomodoro-300x300.jpgانجام کار به صورت Time Boxing علاوه بر ایجاد تمرکز روی کار مورد نظر موجب ایجاد روحیه و انرژی در نفر(ات) می شود. بدین صورت که از تکراری شدن کار جلوگیری می کند , هر وقت که به قول امیر مهرانی نفر می خواهد غرق کار شود دینگ Time Boxing نفررا به شروع یک TimeBox جدید دعوت می خواهد کرد و مسلما در این تایم جدید تغییراتی برای بهبود اوضاع نسبت به تایم قبلی ایجاد خواهد شد که این نیز باعث بهتر شدن کار و با انگیزه شدن نفر نیز خواهد شد.

البته کار به صورت Time Boxingدر ابتدا کمی سخت است بخصوص برای ما که عادت داریم یا کاری را شروع نمی کنیم و یا اگر می کنیم تا تمام نکنیم ازش دست نمی کشیم. برای شروع می توانید از روش پامادور که یک روش Time Box هست نیز استفاده نمایید.

یاشیاسیز

نجات پروژه شکست خورده توسط اسکرام

فوریه 23, 2011 2 دیدگاه

https://sirasad.files.wordpress.com/2011/02/cpr2-300x300.jpg?w=300شاید این حقیقت بسیار تلخی باشد که در عرصه صنعت توسعه نرم افزار تعداد زیادی از پروژه ها با شکست مواجه و در برزخ گرفتار می شوند. نجات دادن و یا بازگردانی این پروژه ها بر روی ریل معمولا کار سختی است زیرا زمانی متوجه می شوند  پروژه مرده است که دیگر امکان بازگردانی وجود ندارد یا حداقل خیلی سخت است.

علت اینکه بازگردانی این پروژه ها سخت یا غیر ممکن می شود این است که دیر متوجه می شویم (دیر با واقعیت روبرو می شویم) پروژه شکست خورده است و در این موقع هم اکثر پل های پشت سرمان را بدون اینکه بدانیم شکسته ایم… . کنترل پروژه رفته رفته از دست خارج شده است – اصلا معلوم نیست چه میزانی از پروژه تکمیل و چه میزانی باقی مانده است – خروجی ها ارائه شده پر از مشکل می باشد – مشتری اعصبانی است – اعتماد بین اعضای تیم از بین رفته است و خبری هم از کار تیمی نیست و … .

در این مواقع اسکرام می تواند کمک کننده به احیای پروژه باشد. یعنی در هر جایی از پروژه که بودیم و با هر متدی که کار می کردیم می توانیم از این به بعد دست به دامن اسکرام شویم تا شاید اوضاع روبراه شود.

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

شاید سوال پیش بیاید که چگونه باید شفاف سازی کرد؟

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

بک لاگ موارد ساخته نشده که دقیقا مانند بک لاگ محصول می باشد و بک لاگ موارد مشکل دار و تست نشده هم شامل آیتم هایی خواهد بود که یا تست نشده اند (تست پذیرش مشتری و تست یکپارچه سازی و … ) و یا مشکل دار هستند. گذشته از اینکه یک یا دو بک لاگ داشته باشید باید بک لاگ (ها) را برآورد نمایید که آن هم بر اساس Story Point  خواهد بود.

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

https://sirasad.files.wordpress.com/2011/02/wayne-rooney-007.jpg?w=460 فرض کنید یک پروژه با زمان 1 سال داشتیم و بعد از 9 ماه فهمیدیم که در حال کج روی هستیم و خواستیم شفاف سازی نماییم. بعد از شفاف سازی فهمیدیم 200 پوینت آیتم داریم و 3 ماه هم وقت. طول اسپرینت های ما هم 4 هفته بود و با اندازه گیری سرعت به این نتیجه رسیدیم که تیم قادر است در هر اسپرینت 10 پوینت انجام بدهد. حالا این 200 پوینت با این سرعت 10 پوینتی به چند ماه کار نیاز دارد؟

بعد از این , مشکل مدیریتی خواهد بود. مثلا مدیریت می تواند با افزایش تعداد نفرات و تیم ها سرعت و ظرفیت انجام کار را بالا ببرد و یا می تواند با رایزنی از دامنه پروژه بکاهد و یا امثالهم.

اما بهترین تصمیم و یا عملکرد مدیریتی در این شرایط می تواند رفع موانع و درگیری های موجود می باشد, موانعی مانند موارد زیر :

  • فشار بر روی تیم
  • تست ها و پروسه های غیر موثر (مانند قوانین کدنویسی شرکتی)
  • فقدان کار تیمی و انگیزه در نفرات
  • انتظارات غیر واقعی
  • عدم تمرکز شرکت بر روی پروژه
  • مدیریت دستور- و – کنترل به جای خود سازماندهی

هر یک از این موارد ذکر شده تاثیر به سزایی بر روی ظرفیت و سرعت تیم و دیگر المان های موفقیت پروژه خواهد داشت مثلا فشار بیش از حد روی تیم باعث از بین رفتن انگیزه در تیم می شود و این نیز باعث افت شدید سرعت خواهد شد و … .

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

یاشیاسیز

آیا شلوار Agile هنوز برای سازمان های ایرانی گشاد است؟

دسامبر 31, 2010 4 دیدگاه

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

https://sirasad.files.wordpress.com/2010/12/happyman.jpg?w=274به طور خلاصه نرم افزار کارآ به محصولی اطلاق می شود که نیازهای جاری مشتری را رفع نماید و قابل گسترش برای پوشش نیازهای بعدی او نیز باشد. اما آیا واقعا در ایران هدف صنعت نرم افزار برآورد کردن نیازهای مشتری است! آیا خروجی های ما در طی این مدت (مثلا 10 سال گذشته) کارآ بوده اند؟

بزرگترین مانع در دست یابی به یک محصول کارآ به نظر من قراردهای بسته می باشد. قراردادهایی وابسته به یک نیاز سنجی اولیه و تخمین زمانی اغلب نادرست. مثلا Aو B را باید در 1 ماه انجام بدهید. انجام A و B در یک ماه حالا با یک تلرانس 1 هفته ای طی یک پروژه , عرضه کننده محصول کارآ نخواهد بود زیرا ما مکلف به تکمیل درخواست ها هستیم و نه ارائه محصول کارآ.  همین دید باعث می شود اگر زمانی نیاز باشد B به C تبدیل شود شاهد اختلافات بزرگی باشیم.

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

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

اما بحث قرارداد بیشتر یک بحث فرهنگی می باشد تا یک بحث فنی. همیشه در قرارداد باید حداقل دو طرف وجود داشته باشند : 1- مشتری 2-مجری قرارداد. هر دو طرف این قرارداد باید به یک سطح فرهنگی و شعوری برسند که من مشتری برای رسیدن به خروجی کارآ باید هزینه کنم و من مجری باید خروجی کارآ ارائه نمایم و اسم این سطح شعوری را می توان چابکی نامید.مشتری چابک و مجری چابک خواهند توانست آغاز گر یک پروژه با خروجی کارآ باشند.

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

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

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

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

چابک شوید و چابک بمانید.

یاشیاسیز

کتاب اسکرام و اکس پی ساده شده

اکتبر 19, 2010 15 دیدگاه

https://i0.wp.com/iragile.com/css/images/scrumBook.gif

کتاب اسکرام و اکس پی ساده شده (چگونه اسکرام را انجام دهیم) نوشته استاد هنریک کنیبرگ می باشد . این کتاب یکی از محبوب ترین و پرطرفداترین کتاب های اسکرام و Agile می باشد به نحوی که اگر واژه Scrum را در گوگل جستجو نمایید این کتاب را در ردیف های اول مشاهده خواهید کرد .

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

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

حوزه هایی که این کتاب پوشش می دهد در مورد آشنایی و پیاده سازی کامل اسکرام می باشد و علاوه بر آن  معرفی و ترکیب روش XP با اسکرام را به طور مفصل بحث  کرده است .

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

علاوه بر این , این کتاب توسط چندین مربی و آمورزگار اسکرام به عنوان مرجع کورس Certified Scrum Master معرفی می شود و می توانید با این کتاب برای ارزیابی کورس مربوطه نیز آماده شوید.

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

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

https://i0.wp.com/iragile.com/css/images/frontcover.gifدر کتاب نحوه مدیریت نوین توسط اسکرام به صورت کامل شرح داده شده است. در مدیریت مشتریان و تیم نقش بسزایی ایفا می کنند که این کتاب توجهی ویژه به  مدیریت نیروی انسانی و مشتریان داشته است .

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

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

امیدوارم توانسته باشیم خدمت کوچکی به جامعه Agile ایران کرده باشم .

در این کتاب چه چیزی هایی خواهید خواند

  • مقدمه و معرفی اسکرام
  • چگونه بک لاگ  محصول را  ایجاد می کنیم
  • چگونه برای برنامه ریزی اسپرینت آماده می شویم
  • چگونه جلسه برنامه ریزی اسپرینت را برگذار می کنیم
  • چگونگی ارتباطات در طول اسپرینت
  • چگونه بک لاگ اسپرینت را انجام می دهیم
  • چگونه اتاق تیم را مرتب می کنیم
  • چگونه جلسه روزانه اسکرام را انجام می دهیم
  • چگونه دموی اسپرینت را ارائه می دهیم
  • چگونه اسپرینت را بازبینی می کنیم
  • چگونگی فاصله دهی مابین اسپرینت ها
  • چگونگی انجام قرار دادهای قیمت بسته و برنامه ریزی Release
  • چگونه XP را با اسکرام ترکیب می کنیم
  • چگونه تست می کنیم
  • چگونه چندین تیم اسکرام را اداره می کنیم
  • چگونه تیم های پراکنده جغرافیایی را اداره می کنیم
  • چک لیست مدیران اسکرام
  • معرفی خواندنیهای مفید

مخاطبین کتاب

  • مدیران شرکت های توسعه نرم افزار
  • مدیران پروژه نرم افزاری
  • مدیران اسکرام (Scrum Mater)
  • توسعه دهندگان نرم افزار

برای تهیه این کتاب می توانید به این لینک مراجعه فرمایید.

یاشیاسیز

آیا Agile نیازی به Technical Excellence دارد؟

اوت 24, 2010 4 دیدگاه

Technical Excellence یکی از مبحث های Agile می باشد که یا مورد محبت زیاد و یا کم مهری بیش از اندازه  قرار می گیرد .  البته این مسئله صرفا برای ایران نیست و تیم های تازه کار Agile با این مشکل مواجه می شوند.  در آیه شماره 9 اصول توسعه چابک آمده است :

https://sirasad.files.wordpress.com/2010/08/images.jpg?w=225Continuous attention to technical excellence
and good design enhances agility

معنی لفظی این آیه : توجه مداوم به برتری فنی و طراحی خوب باعث افزایش چابکی می شود . اگر بخواهیم این اصل را از اصول توسعه چابک تفسیر نماییم به این نقطه خواهیم رسید که در توسعه چابک مسائل تکنیکی و فنی ( که در متدلوژی های دیگر در نظر گرفته نمی شدند) با ارزش و کلا جزو پروسه چابک سازی نامیده  شده اند .  به عبارت ساده تر در این اصل تیم های Agile را به حفظ برتری فنی و تکنیکی مداوم دعوت کرده اند و در این حد این قضیه مهم خوانده شده است که گفته اند : «باعث افزایش سطح چابکی می شود » که در هیچ یک از اصول توسعه چابک به صراحت به این مسئله اشاره نشده است یعنی این مورد تاثیر بیشتری نسبت به بقیه خواهد داشت .

ولی طبق تجربه من عرض می کنم که این اصل را قبول ندارم و این را می توان بیان کنم که : » بدون Technical Excellence چابک بودن امکان پذیر نخواهد بود » . و دغدغه نوشتن پستی فقط و فقط بیان لزوم برتری فنی برای تیم های Agile می باشد .

قبل از بیان لزوم برتری فنی لازم است تعریفی از Technical Excellence داشته باشیم :

Technical Excellence یا همان برتری فنی به معنی استفاده از ابزارها ,  روش ها ,  تکنیک ها ,  متد ها و … برتر در پروسه طراحی ,  تست و کد نویسی می باشد . از جمله Technical Excellence ها مورد بحث و مهم در زمینه چابک Unit Testing , Refactor , Continues Integration  , Clear Code , Automated Tests , TDD , … .و البته که تمام موارد فنی جزو این برتری فنی حساب خواهند شد .

برای اثبات مطلب ارائه شده (بدون Technical Excellence چابک بودن امکان پذیر نخواهد بود) کافی است با هم یک مثال کوچک را بررسی نماییم : در ارزش 4 ام بیانیه توسعه چابک آمده است :

Responding to change over following a plan

بیان شده است که ما به عنوان یک تیم چابک باید بتوانیم پذیرای تغییرات باشیم .

همانطور که می دانید تغییرات آفت توسعه نرم افزار هستند و این تغییرات باعث شکست پروژه های خیلی بزرگ شده اند و البته اگر بتوانیم این تغییرات را کنترل و مدیریت کنیم  علاوه بر رضایت مشتری به سود آوری خوبی خواهیم رسید .دقیقا دو روی  یک سکه هستند  یک رو رضایت مشتری و سود آوری و یک روی دیگر نارضایتی و  ضرر و زیان .

فرض کنید ما یک تیم Agile هستیم که اعتقادی به Technical Excellence نداریم و این را هم می دانیم که برای پذیرایی از تغییرات باید کد های تمیزی داشته باشیم . برای داشتن کد تمیز باید کدها Refactor  شده باشند . برای رفاکتور شدن کد های نیاز به تست های اتوماتیک و کلا Unit Testing داریم . Unit Test ها باید برروی یک Continues Integration قرار بگیرند .

https://sirasad.files.wordpress.com/2010/08/b5391b73f65841c4a9c49d0e2c9aec2d1.jpg?w=376حالا ما به عنوان یک تیم Agile چگونه می خواهیم بدون Technical Excellence پذیرای تغییرات باشیم ؟ اگر نمی خواهیم پذیرای تغییرات باشیم ,  پس چگونه اسم خودمان را تیم Agile یا چابک نامیده ایم ؟

این فقط یک مثال کوچک از لزوم Technical Excellence بود که خواستم از این طریق عرض کنم : موارد و اصولی که در بیانیه توسعه چابک بیان شده است ,  همینطوری کشکی نیست و نمی شود گفت که این به درد ما نمی خورد بنداز دور . نوشتن چنین نوشته هایی از آنجایی برای من اهمیت پیدامی کند که می شنوم : » ما Agile کار می کنیم  ,  ولی Unit Test نداریم . «

البته این معضل فقط برای Agile نیست ,  بنده تیم هایی (گردن کلفت) را دیدم که ادعای کار با RUP را می کردند ولی در واقع همان سنت حسنه Waterfall را ادامه می دادند . پیشنهاد من این است که  Agile  کار نکنیم بلکه Agile باشیم که اینگونه همه چیز حل خواهد شد .

به امید تیم های Agile در سرتاسر جهان .

یاشیاسیز

مطالب مرتبط با این بحث :

آشفته بازار توسعه نرم افزار

ژوئیه 30, 2010 40 دیدگاه

https://sirasad.files.wordpress.com/2010/07/bad-project-management.jpg?w=212در پست قبلی در مورد معضل «مدیر پروژه شدن  برنامه نویسان» صحبت کردیم که بسیار هم جنجالی شد . شرکت کنندگان در این بحث را می توان به دو دسته کلی تقسیم کرد : 1- کسانی که با من هم نظر بودند و اعتقاد داشتند که برای یک مدیر پروژه دانش مدیریت بالاتر از دانش برنامه نویسی است 2- کسانی که اعتقاد داشتند که دانش برنامه نویسی در اولویت قرار دارد .

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

برای مثال یکی از دوستان در یکی از شرکت های آمریکا کار می کند کار این شرکت توسعه سیستم HIS است ,  این شرکت فقط 2500 نفر برنامه نویس دارد : خوب من به هیچ وجه این 2500 نفر را به دست یک برنامه نویس واگذار نمی کنم و تکنیکی که برای مدیریت HR توسط مدیریت پروژه لحاظ شده است این است که این برنامه نویس ها به تیم های 9-8 نفر تقسیم شده اند و برای هر تیم یک نفر برنامه نویس حاذق که کمی با اصول رهبری تیم آشنا است به عنوان سرپرست تیم گمارده شده است : توجه داشته باشید که این سرپرست تیم , مدیر پروژه نیست . اگر از این سرپرست حساب کنیم شاید مدیر پروژه 5 سطح بالاتر در چارت سازمانی قرار گرفته باشد .

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

https://sirasad.files.wordpress.com/2010/07/2259360231_6f60460770.jpg?w=300همانطور که خودتان هم می دانید با توجه به وضع فاجعه بار صنعت توسعه نرم افزار ما لازم است که از مدیران پروژه چند کاره (مدیر پروژه ,  برنامه نویس ,  تحلیل گر ,  طراح , DBA  , سبزی خرد کن , آبمیوه گیری و چندین عملکرد دیگر ) در این صنعت استفاده شود . علت اینکه لازم است از این عزیزان چند کاره استفاده شود , تشکیلات و سازماندهی های موجود در شرکت های توسعه نرم افزار می باشد . شرکت های توسعه نرم افزار ما ( که به جرآت می توانم بگویم که تعداد شرکت های ما از تعداد شرکت های توسعه نرم افزار در آمریکا بیشتر است ) دارای تشکیلات ناقص و نادرست می باشند .

مدل تشکیلاتی موجود در بازار ایران از دیدگاه من به شرح ذیل می باشد :

  • شرکت های یک نفره : این شرکت های یک نفره شاید 30% بازار را تشکیل داده باشند . این عزیزان کسانی هستند که معمولا پروژه هایی را از بیرون صید و در خانه ملوکانه آن را توسعه و در مکان مشتری تحویل می دهند . این شرکت که فقط یک نفر دارد ( و در بعضی اوقات دو نفر ) به دلیل پایین بودن بحث مشارکتی قابل بحث نیستند زیرا آن یک نفر چند کاره 100% است . در تقبیح این شرکت ها نمی توانم صحبتی داشته باشم زیرا دوستان Freelancer از دست ما ناراحت می شوند . و قابل ذکر است که وضع درآمدی این شرکت ها خوب نیست و به قول سهراب : تکه نانی دارم ,  خرده هوشی ,  سر سوزن ذوقی , روزگارم بد نیست … . قانع هستند دیگه .
  • شرکت های برنامه- نویسی : این شرکت ها معمولا از تعدادی دانشجو و یا فارغ التحصیل دانشگاهی تشکیل شده است که دور هم با یک سرمایه کم جمع شده اند تا تمام پروژه را صید بکنند و در کسری از ثانیه آنها را توسعه بدهند . همه دوستان در این شرکت ها در یک سطح هستند و کسی بر کسی رئیس یا مدیر نیست  . یعنی در این شرکت ها چند مدیر پروژه چند کاره داریم . به نظر من  این شرکت ها معمولا موفق نیستند و بعد از مدتی باید جمع شود و چند شرکت جدید به جای انها باز شود : بدلیل اینکه همه این دوستان ازنظر تکنیکی جلو هستند و توانایی هایی فقط در حوزه توسعه نرم افزار دارند و تقریبا به دلیل نداشتن مدیریت متمرکز محکوم به فنا هستند . این شرکت ها توانایی جذب مدیر پروژه واقعی را ندارند زیرا اولا بودجه لازم را ندارند و دوما هر کدام از دوستان برای خودش مدیر پروژه ای است . علاوه بر مدیر پروژه ,  این شرکت ها در کسب و کار هم موفق نیستند و توانایی کسب در آمد را معمولا ندارند . معمولا اعضای شرکت اول (تک نفری) با این شرکت به شرکت سوم نقل مکان می کنند تا بلکه به روزگاری خوش دست یابند .
  • https://sirasad.files.wordpress.com/2010/07/usachild3.jpg?w=472شرکت های سرمایه ای : شرکت های سرمایه ای معمولا با سرمایه اندک یک یا نفر چند شریک استارت می خورد . هدف اصلی این سرمایه گذاران , سود بیشتر با هزینه کمتر است : پس  این دوستان تمام تلاس خود را خواهند کرد تا هزینه کمتری بکنند  . این شرکت ها معمولا چند نفر تازه کار مانند دانشجویان را با حقوق خیلی کم استخدام می کنند و برای این افراد برنامه نویس حاذقی (از شرکت یک یا دو )  با حقوق متوسط و  البته با مارک مدیر پروژه استخدام می کنند تا در واقع جمع ما کامل شود . این برنامه نویس بدبخت هم باید این تازه کاران را راه بیندازد ,  هم پروژه (ها) را تحلیل و طراحی نماید,  هم باید رضایت مشتری و رضایت صاحاب (ان) شرکت رو جلب نماید ,  هم باید مدیریت بکند , هم باید برنامه نویسی بکند و … . ( عجب چند کاره ای !! آقا اینا رو از کجا گرفتید ؟ خانم من تو خونه یکی از اینها رو لازم داره ,  این رو از دانشگاه شریف گرفتیم ,  اگر می خواهید یکی هم سر راه براتون بگیرم ,  سبزی هم پاک می کنه ؟ آره بابا ,  بچه هاتون رو هم براتون نگه می داره) . واقعا در اینگونه شرکت ها PMP نمی تواند کار بکند زیرا اصلا بستر لازم آماده نیست .
  • به نظر من شرکت های سرمایه ای اصلی ترین ضربه ها را وارد بدنه صنعت توسعه نرم افزار کرده اند . اینها بدون اینکه خرج بکنند می خواهند سود برداشت بکنند : دولت باید در این حوزه وارد بشود زیرا که کل کار در اینجا در دست بخش خصوصی افتاده است و بخش خصوصی کاملا گند زده به اوضاع این صنعت . اصل 44 در هیچ جا به کاملی صنعت توسعه نرم افزار اعمال نشده است . یعنی از اول دولت این صنعت را به حال خود را رها کرده است و این صنعت خود به خود حرکت می کند . نه دولت حمایت می کند نه دولت نظارت می کند ,  نه دولت قانون گذاری می کند و همین طوری می شود که شرکت هایی مثل قارچ هر روزه متولد می شوند و هر روزه از بین می روند . (شاید هر روزه چند در چند تا شرکت باز و در چند تا شرکت تخته می شود ) .

    https://sirasad.files.wordpress.com/2010/07/asleep.jpg?w=425کسی که شرکت های نوع اول و یا دوم را تاسیس می کند مجبور است زیرا چاره  دیگری ندارد . چندین سال از بهترین عمر خود را در دانشگاه ها و یا کتاب ها و یا سایت ها صرف یادگیری بهترین و جدید ترین مطالب کرده است و امروز حق دارد که از داشن خود پول در بیارد . ولی شرکت های سرمایه ای چه ؟ دیر آمده اند و زود می خواهند بروند . این ها ضربه های کشنده ای وارد این صنعت کرده اند . هم بازار را خراب کرده اند ,  هم نیروی کار را اذیت کرده اند ,  هم آبروی این صنعت را برده اند . همه روزه چندین عنوان نرم افزار حسابداری وارد بازار می شود ,  آیا کسی به اینها نظارت دارد ؟ آیا کسی پیدا می شود که بدلیل پایین بودن کیفیت نرم افزار آن را از بازار خارج نماید؟ آیا کسی پیدا می شود که به درد دل این برنامه نویس های مشغول در این شرکت ها گوش کند ؟ آیا کسی پیدا می شود که حقوق اولیه اینها را از صاحبان شرکت طلب کند ؟

    دولت حتما باید در حوزه توسعه نرم افزار وارد بشود و قوانینی را وضع بکند . البته قوانین دست و پاگیر در زمینه احداث شرکت نه بلکه در زمینه حمایت . به نظر من دولت باید در دو زمینه قوانینی را به تصویب برساند :

  • حمایت از نیروی انسانی شرکت ها : دولت باید قوانینی را وضع بکند که مثلا هر شرکتی که تاسیس می شود باید نسب به پروژه , نیروی انسانی لازم و نه حداقل ها را استخدام بکند . مثلا باید مدیر پروژه داشته باشد (چطور برای ساختمان سازی چند تا مهندس عمران الزامی است ؟ ) باید نیاز های برنامه نویس ها تامین شود (مانند دو مو نیتور , ساعاتی کاری استاندارد , ابزار لازم و … ) . در صورتی که قوانین اجرا نشد , در آن مجموعه باید تخته شود .
  • حمایت از شرکت برای توسعه نرم افزار کارا : به جرات می توانم بگویم از نرم افزار های تولیدی تا به این روز شاید 1% کارا و به درد بخور باشد . دولت باید از شرکت های مورد بالا حمایت بکند تا بتوانند نرم افزارهایی با استانداردهای جهانی و کآرا توسعه بدهند . (حمایت مالی , ارائه تسهیلات بین المللی و … ) .

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

  • شرکت هایی مافیایی : همه دوستان شاغل در صنعت نرم افزار با این شرکت ها آشنا هستند . البته شاید تعداد این شرکت ها کمتر از انگشتان دو دست باشد ولی بیشتر از تمام شرکت ها ی دیگر در آمد دارند . این شرکت با زدو بند هایی که انجام می دهند روز به روز رشد می کنند و تبدیل به مافیای نرم افزار می شوند .  دولت باید در این زمینه هم وارد صحنه شود .

من واقعا به نوبه خودم بسیار شرمنده هستم که در این بازار آشفته کار می کنم . بعضی از اوقات که در مورد توسعه نرم افزار خوب و یا Agile مقاله می نویسم به یاد شعر معروف می افتم :  خانه از پای بست ویران است *** خواجه درفکر نقش ایوان است  …

برای نتیجه گیری هم قابل ذکر است که حق با دوستان است :  در این بازارخودمون PMP کیلوئی چند ؟ برنامه نویس های خودمون مدیریت پروژه می کنند باقلوا .

یاشیاسیز