بایگانی

Archive for the ‘Programming’ Category

آیا 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 در سرتاسر جهان .

یاشیاسیز

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

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

ژوئیه 26, 2010 24 دیدگاه

https://sirasad.files.wordpress.com/2010/07/cartoon_planning.gif?w=300این جریان مدیر پروژه شدن برنامه نویس ها در ایران حکایتی بس طولانی دارد که در این پست قصد مختصر بررسی در این باب را دارم . قبل از شروع بحث موردنظر  لازم می بینم  نظر خودم را در مورد لزوم مدیر پروژه در پروژه های توسعه نرم افزار عرض کنم : به نظر بنده در 90% پروژه های توسعه نرم افزار در ایران نیازی به نقشی با نام مدیر پروژه نیست زیرا این پروژه  ها دارای خصوصیات یک پروژه واقعی نیستند که نیازی به مدیریت پروژه باشد : مثلا به مدیر پروژه بودجه اختصاص داده نمی شود که او بتواند Cost Management بکند یا بتواند نیروی کار مورد نیاز را استخدام بکند و یا … . به طوری کلی مدیر پروژه ای که در اینگونه پروژه ها فعالیت می کند دارای مجوز و اختیارات لازم نیست : یعنی عملا Iron Triangle پروژه در دستان او نیست . البته علاوه بر اینکه مالکان شرکت او را محدود کرده اند ,  او وظایف یک مدیر پروژه را نیز انجام نمی دهد . برای مثال یک شرکت آگهی زده است که :

به یک مدیر پروژه نرم افزاری  حاذق نیازمندیم با شرایط ذیل :

  • توانایی کامل طرح ریزی کامل پروژه
  • توانایی مدیریت
  • توانایی برنامه نویس با زبان #C

کاملا از شرایط درخواستی معلوم است کسی که قرار است این کارها را انجام بدهد اسمش مدیر پروژه نیست (البته با توجه به تعاریف انیستیتو PMI ) . در ایران انتظار میرود که مدیر پروژه کل پروژه را طرح ریزی و طراحی کند . یعنی او عملا کار تحلیل گر و طراح را انجام می دهد  . بلی بنده قبول دارم که مدیر پروژه باید توانایی طرح ریزی داشته باشد ولی نه تحلیل و طراحی محصول  در بعد فنی و تکنیکی مثلا استخراج Class Diagram ؟ ! بلکه او در سطح مدیریت  باید طرح ریزی نماید : Road Map پروژه را مشخص کند ,  ریسک های پروژه را معلوم بکند و … .

انتظار بعدی این است توانایی مدیریت داشته باشد : خوب خیلی خوب است ولی توانایی مدیریت یعنی اینکه تقسیم وظایف برعهده او خواهد بود . مدیریت منابع انسانی (HR) تقسیم وظایف نیست . (مثلا از او انتظار میرود که وظایف برنامه نویسان را در هر ساعت مشخص کند) .

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

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

حکایت اینکه برنامه نویس مدیر پروژه می شود دقیقا مانند حکایت دندانپزشک شدن سلمونی ها در قدیم بود :

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

به نقل از نادر خرمی راد

http://images.travelpod.com/users/uncle_davros/the_world.1146204120.dhaka_-_019_street_dentist.jpgهم اکنون طبق گفته بالا ما مدیر پرژه نداریم بلکه سلمونی ها و یا برنامه نویس ها دارند اینکار رو برای ما انجام می دهند . منتهی تنها دلیلی که باعث می شود که یک برنامه نویس احساس مدیر پروژه بودن بکند چیزی نیست جز Halo Effect . یعنی طرف به عنوان برنامه نویس خیلی موفقه و به همین دلیل یک هاله نوری او را احاطه می کنه که می تواند به عنوان مدیر پروژه کار کند و بدین گونه می شود که برنامه نویس مدیر پروژه می شود .

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

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

یاشیاسیز

دنیای چابک در یک فایل Pdf

ژوئیه 2, 2010 2 دیدگاه

https://sirasad.files.wordpress.com/2010/07/pdf.jpg?w=400یکی از دوستان به نام سعید اسفندی لطف کردند و برای راحتی دوستان دیگر , کل مطالب وبلاگ را (تا به این تاریخ) به صورت فایل PDF در آوردند . در صورت علاقه و تمایل  می توانید از این فایل به طریق لینک زیر استفاده فرمائید.

دانلود فایل Pdf دنیای چابک

از دوست گرامی که زحمت کشیده اند و این فایل را آماده نمودند نهایت تشکر را دارم .

یاشیاسیز

تست محصول در Agile

مه 28, 2010 5 دیدگاه

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

https://sirasad.files.wordpress.com/2010/05/doctorninja-tm.jpg?w=275بنده به دو دلیل با تئوری بالا مخالف هستم و عقیده دارم باز هم  اگر Tester به تیم توسعه اضافه گردد دوباره برنامه ها پر از باگ خواهند بود : 1- Tester خوب در ایران وجود ندارد و یا خیلی کم است 2-  Tester نمی تواند تمام آزمایش های لازم را انجام بدهد و آزمایشات کامل زمانی می تواند اتفاق بیفتید که برنامه نویس هم تست نماید .

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

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

به طور کلی Agile دید مثبت و خوبی نسبت به تست دارد و کلا این مقوله در ارزش ها و اصول بیانیه توسعه چابک پیش بینی شده است .  اصل 9 بیانیه توسعه چابک اشاره غیر مستقیمی به لزوم تست دارد .TDD روشی می باشد که در متدهای Agile به عنوان روش تست معرفی شده است .

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

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

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

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

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

پیاده سازی یک ارزش در محیط چابک می تواند به صورت زیر می باشد :

  • ارزش یا User Story شناسایی می شود و مستند می شود.
  • ویژگی های ارزش شناسایی و مستند سازی می شود.
  • هر کدام از ویژگی های یک ارزش به صورت تست هایی پیاده سازی می شوند.
  • ارزش بر اساس الگوی تست موجود کد نویسی می شود .

همانطور که مستحضر می باشید گام های بالا همان گام های TDD می باشند ولی این گام های وظیفه چه کسی می باشد ؟

  • گام اول – ارزش یا User Story شناسایی می شود و مستند می شود : وظیفه کل تیم توسعه می باشد .
  • گام دوم – ویژگی های ارزش شناسایی و مستند سازی می شود : وظیفه Tester های تیم و توسعه دهندگان می باشد .
  • گام سوم و چهارم-  وظیفه برنامه نویسان عزیز می باشد .

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

چابک شوید  , TDD کار کنید ,  تغییرات را با آغوش باز پذیرا باشید و چابک بمانید .

یاشیاسیز

طراحی وب سایت همراه با شام و نهار فقط 1000 تومان

فوریه 20, 2010 56 دیدگاه

تعجب نکنید , ما برای شما سایت طراحی می کنیم فقط با 1000 تومان  با یک وعده نهار و شام . سایت های ما بسیار پیشرفته هستند به صورتی که تمام امکانات سایت Face Book  فقط ماژول اجتماعی  سایت شما خواهد بود ,  سایتی مانند  YouTube ماژول تفریحی شما خواهد بود ,  Rapidshare هم ماژول  فایل شیرینگ شما خواهد بود . اصلا هر امکاناتی که شما بخواهید را ما می تونیم طراحی نماییم . یکی از مسئولین بلند پایه کشوری به خاطر دست یافتن ما به این اقتدار ملی و سربلندی چنین گفت :

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

https://i1.wp.com/rlv.zcache.com/will_write_code_for_food_shirt-p235780280084662100t5tj_325.jpg

اگر شما در گوگول کلید واژه «طراحی سایت فقط» را جستجو نمایید به 1 میلیون و چهار صد هزار مورد بر خورد می کنید . ما این همه طراح وب سایت در کشور داریم که همه اشان مفت واسه شما سایت طراحی می کنند ؟!  رنج و حدود قیمتی که من توانستم به دست بیارم این است :  طراحی سایت از 5 هزار تومان داریم تا 5 میلیون ریال و هاستینگ هم داریم از 3 هزار تومان تا 300 هزار تومان . به به ,  کی میگه ما تورم داریم ؟ این همه ارزونی ,  واقعا مفته .

واقعا چرا اینگونه شده است ؟ آیا طراحی وب سایت های اینترنتی اینقدر آسان شده است که بچه هایی که کشاورزی خونده اند هم در کنار باغبانی سایت هم طراحی می کنند  ؟ یا ما متخصص در زمینه نرم افزار زیاد داریم ؟  آیا دانشگاهای ما Web Designer  تولید و عرضه می نماید ؟

فرض کنید سایتی به مبلغ 20 هزار تومان ساخته می شود . این سایت حداقل 5 صفحه دارد . اگر ما از تکنولوژی پیچیده HTML و از محیط بسیار مشکل Front Page هم برای طراحی سایت استفاده نمایم حداقل 1 روز باید وقت بگذاریم . حداقل باید 5 یا 6 تا عکس در فتوشاپ حاضر نماییم . کل سایت رو فرض کنیم در دوروز کاری 10 ساعته برپا کردیم . برای هر روزه این بنده خدا 10 هزار تومان می افتد . آیا عمله ها هر روز بیشتر از این در نمی یارند ؟

مشکل کجاست ؟ چه کسی مشکل دار است ؟  چه کسی گناه کار است ؟

چند تا دلیل را می توانم برای این مشکل بشمارم که اگر ناقص بود شما تکمیل نمایید :

  1. بی صاحاب بودن رشته نر م افزار و عدم داشتن نظام مهندسی – آقا هر کی با هر رشته ای حتی نساجی (من خودم سراغ دارم) میره یک دوره طراحی وب سایت میگذرونه و میاد میشه وب Designer . آقا این واقعا جفاست  . آقا من میام نساجی بکنم ؟ آقا من میام  کشاورزی بکنم ؟ بردار برو رشته خودت دیگه . اگر نظام مهندسی داشتیم جلوی این مورد گرفته می شد و از هرکجا مانده و از هر کجا رانده طراح سایت و یا مهندس نرم افزار نمی شد .
  2. فارغ التحصیل نرم افزار هزار هزار – من نمی دونم ما فقط تو ایران رشته نرم افزار رو  داریم ؟ بابا برید هوا فضا ,  برید معدن ,  برید باغچه بانی ,  برید فوتبالیست بشید والله این رشته نه پول داره و نه هیچ چیز دیگر .
  3. عدم اعتنای مسئولین به این هزار هزار فارغ التحصیلان – این طوری می شود که این برادر و اون خواهر کار گیرش نمی یاد و میره واسه 5000 تومان سایت طراحی می کنه و میزنه چشم بازار رو در میاره .
  4. بیکاری و عدم وجود فرصت های شغلی مناسب و زیاد – بدلیل بی اعتنایی مسئولین و یا عدم توانایی  در زمینه اشتغال زائی فارغ التحصیلان دانشگاهی و برده کشی و بیگاری کشی بخش خصوصی از این فارغ التحصیلان و بیکاری اینطوری می شه که این عزیزان برای نان شب سایت طراحی می کنند.
  5. توهم وب Designer بودن :  بعضی از عزیزان  و به خصوص کسانی که تازه با مقوله طراحی سایت آشنا شده اند با یاد گیری Front page و  کمی HTML توهم وب دیزاین میزنند . برادر طراحی وب سایت به همین سادگی ها نیست . سایت فقط Template نیست که اون را از Template Monster کش بری و بشی طراح سایت . هر روز یک تکنولوژی تازه میاد هرروز یک Framework  هروز یک شماره به web اضافه می شود ,  راستی الان تو وب چندیم ؟ 2 یا 3 .
  6. توهم راحت بودن طراحی Web site نسبت به Desktop Application .
  7. در دسترس بودن CMS های فراوان به خصوص برای PHP کارها . من به جرات می توانم یکی از مشکلات اساسی و بازار خراب کن های صنعت طراحی وب سایت همین PHP کارها هستند . البته نه PHP کار بلکه تعمیر کار Joomla بگوییم بهتر است .

زیاد گفتیم و نوشتیم ولی این مسئله همانند بسیاری دیگر از مشکلات این مملکت درست بشو نیست ,  پس الکی خودمان را خسته نکنیم  . ولی از دوستانی که  در این کار هستند یک خواهش دارم :

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

یاشیاسیز

دسته‌ها:Programming

پروسه تولید نرم افزار

فوریه 18, 2010 8 دیدگاه

۱https://i0.wp.com/www.hydramotion.com/images/XL7/process%20viscometer.jpg– برنامه نویس کدهایی رو تولید میکنه که فکر میکنه کدها عاری از هر نوع خطا و باگی است .

۲- محصول تست میشه و ۲۰ تا باگ پیدا میشه .

۳- برنامه نویس ۱۰ تا از اون خطاها رو حل میکنه و برای بخش تست نرم افزار هم توضیح میده که اون ۱۰ تای دیگه واقعا باگ نیستند .

۴- بخش تست در هنگام تست محصول ۵ تا باگ دوباره از اون ۱۰ تایی که حل شده بود پیدا میکنه و علاوه بر اون ۱۵ تا باگ جدید دیگه .

۵- مرحله ۳و۴ سه بار تکرار میشه .

۶-بخش فروش به برنامه نویس ها و تسترها فشار میاره که زودباشید نرم افزار رو Release کنید و این گونه میشه نرم افزار به دست کاربر میرسه .

7-کاربر 137 تا باگ جدید پیدا میکنه .

8-برنامه نویس های اصلی تولید این محصول باهاشون تسویه میشه و همشون از کار برکنار میشند .

9-تیم برنامه نویسی جدید تقریبا تمام اون 137 تا باگ رو رفع میکنند اما باعث به وجود اومدن 456 تا باگ جدید میشند.

10-شرکت مجبور میشه از یه شرکت دیگه برنامه نویس قرض کنه تا این 738 تا باگ رو رفع بکنند .

11-برنامه نویس خبره که از اون یکی شرکت اومده این کدها رو قبول نداره و میگه باید از اول بنویسه .

12-برنامه نویس کدهایی رو تولید میکنه که فکر میکنه کدها عاری از هر نوع خطا و باگی است .

و این جریان ادامه دارد…

دسته‌ها:Programming برچسب‌ها:

برنامه نویس زن از رویا تا واقعیت

فوریه 15, 2010 29 دیدگاه

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

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

مشکل کجاست ؟ آیا ما متخصص زن در زمینه گسترش نرم افزار نداریم ؟

بر طبق شنیده ها و دیده ها بیشترین خروجی در دانشگاههای ایران بعد از رشته های تجربی  و علوم انسانی رشته نرم افزار می باشد . و باز براساس تجربه بیشترینhttps://i1.wp.com/public.bay.livefilestore.com/y1paJOE-S3SosYKACtatLa1hL7NhdZPlOsVjgAWjOyF3ZUPEyXSEWv84PXIRMMi6h7KCFjR-BmczINKiN_DYHVnuA/319edaeaeb7c8ed71d7e9abedb001d25_full.jpg اعضای رشته نرم افزار را خانم ها تشکیل می دهند . معمولا در کلاس ها شاهد این هستیم که دو سوم کلاس مونث می باشد .  معمولا بهترین نمرات را هم خانم ها کسب می کنند و با نمرات عالی فارغ التحصیل می شوند . پس چرا با این وجود خانم ها در پایین ترین نقش های برنامه نویسی فعالیت می کنند ؟

یک برنامه نویس خوب چه ویژگی هایی دارد ؟

  • Passion : اشتیاق و عشق علاقه به امر برنامه نویسی
  • Self-teaching and love of learning : عشق به یادگیری و توانایی خود آموزی
  • Intelligence : با هوشی
  • Hidden experience : تجربیات قبلی که پنهان است و در موقع کار نهان می شود
  • Variety of technologies : آشنایی به فن آوری های گوناگون
  • Formal qualifications : مدارک بین المللی  و معتبر در زمینه گسترش نرم افزار

نقل قول  شده از inter sections

ویژگی هایی که در بالا برای یک برنامه نویس خوب برشمردیم فکر کنم همان کلید معماست .

  • خانم ها اشتیاقی در زمینه برنامه نویس ندارند یا دست کم به اندازه آقایان ندارند ,  اشتیاق خانم ها در عطر و ادکلن و لباس مجلسی است . برنامه نویس واقعی مد و ظاهرش Null می باشد .
  • عشق به یادگیری و توانایی خود آموزی هم که در خانم ها در کمترین حد ممکن می باشد .
  • یکی از دلایل اصلی هم باهوش نبودن خانم ها است .( من نمی دونم اگر این مادام کوری نبود اسم کدام دانشمند خانم در تاریخ باقی می موند)
  • تجربیات قبلی که پنهان است و در موقع کار نهان می شود را هم چون آنقدر مشغله در زمینه انتخاب عطر و ادکلن و لوازم آرایشی دارند که همه این تجربیات در قعر مغازه فروش لوازم آرایشی دفن می شود .
  • آشنایی به فن آوری های گوناگون هم که مستلزم داشتن اشتیاق و توانایی خودآموزی می باشد (بدون شرح و نتیجه گیری)
  • مدارک بین المللی  و معتبر در زمینه گسترش نرم افزار هم که نداریم و فقط آنهایی را داریم که دانشگاه به ما داده است و حوصله هیچ چیزی دیگر را نداریم .

لازم به یادآوری است که همه خانم ها اینگونه نیستند ولی باز عامه خانم های شاغل در زمینه IT این گونه می باشند  .

اگر خانم ها اینقدر در زمینه تولید نرم افزار در حد پایین قرار دارند ,  پس چرا در شرکت های تولید نرم افزار مورد استفاده قرار می گیرند ؟

چند دلیل می تواند باعث این قضیه شود که من چند تا از آنها را نام می برم :

  • دستمزد پایین خانمها
  • حرف شنوی و مطیع بودن خانم ها
  • می تونید سرشون راحت داد بزنید
  • می تونید پرداخت پولشون رو به تعویق بیندازید
  • بر علیه شما شور و جلسه نمی کنند
  • بعد شما برای خودشان دکه و مغازه باز نمی کنند
  • می تونید براشون کلاس بذارید

و دلایلی دیگر …

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

این مطلب نیز پیشنهاد می شود : 9 نشانه برای پی بردن به برنامه نویس بودنتان

یاشیاسیز

دسته‌ها:Programming برچسب‌ها: