از اشتباهاتی که اعضای تیم های نرم افزاری ناخواسته دچار آن می شوند تمرکز بر فرآیند است. بسیار پیش آمده است که پس از ساعتها و حتی روزها کار بر روی معماری یک سیستم نرم افزاری خود را غرق در فرآیند کاری آن یافته ام اما به سودمند بودن خروجی آن برای مشتری توجه چندانی نداشته ام. مگر نه اینکه هدف نهایی از هر صنعت و تجارتی کسب پول است؟ آیا یک معماری عالی که منجر به ارزش افزوده نشود معماری خوبی است؟
البته واضح است که در بسیاری از موارد یک فرآیند خوب - مستقیم یا غیر مستقیم - منجر به ارزش افزوده می شود. مثلا یک معماری خوب منجر به کاهش هزینه پشتیبانی و توسعه آتی سیستم خواهد شد. اما آیا می توان صرفا یک طراحی را چون از الگوهای استاندارد پیروی می کند و اینکه بر مبنای best practice ها بنا شده است خوب دانست؟
در همین زمینه مطلب زیر را از سایت Microsoft کپی کرده ام:
Promote results and benefits, not processes. Most people don’t care how you help them reach their goals, as long as you do it with integrity, efficiency, and within their budget. Instead of talking about how you work, be clear about your expertise and the changes people can expect from working with you. Get into the habit of asking clients for testimonials and referrals and consider writing (or hiring someone to write) case studies on successful engagements you’ve had. The most effective promotion comes from satisfied customers.
+ نوشته شده در چهارشنبه 30 بهمن1387ساعت 16:27 توسط علی نوبر
|
یک بار یک دانشجوی خارجی از پرفسور محمود حسابی پرسید، "می گویند شما از جهان سوم آمده اید ،جهان سوم چگونه جایی است؟ "
استاد جواب دادند " جهان سوم جایی است که اگر بخواهی کشورت را آباد کنی، خانه ات خراب خواهد شد و اگر بخواهی خانه ات آباد شود باید در تخریب کشورت بکوشی"
+ نوشته شده در پنجشنبه 24 بهمن1387ساعت 10:30 توسط علی نوبر
|
+ نوشته شده در چهارشنبه 23 بهمن1387ساعت 15:27 توسط علی نوبر
|
همه ما گاهی در پروژه های کوتاه مدت با تعداد قابلیت های محدود درگیر بوده ایم. در این شرایط چه میزان به طراحی اهمیت داده اید؟ آیا کماکان روی یک طراحی خوب پافشاری کرده اید یا بر وسوسه آن غلبه کرده و به توسعه نرم افزار بدون طی مراحل طراحی تن داده اید؟ برای برخی پیاده سازی نرم افزار فاقد طراحی در حکم خیانت(!) است اما آیا همه نرم افزارها نیاز به طراحی دارند یا می توان گاهی از خیر طراحی گذشت؟
در نمودار زیر خطی فرضی مشاهده می کنید که به نظر Martin Fowler نقطه تصمیم گیری در مورد وجود یا عدم وجود طراحی در نرم افزار است. اگر میزان قابلیتها (و البته میزان زمان و منابع مصرفی) نرم افزار مورد نظر پایین تر از این خط باشد، ممکن است تصمیم گیری در مورد عدم وجود طراحی معقول باشد. اما اگر عملکرد و قابلیتهای نرم افزار تحت بررسی شما بالاتر از این خط باشد، "اوصیکم بالطراحی".
سوال اساسی اینجاست که مکان مناسب قرارگیری این خط کجاست؟
نویسنده مطلب معتقد است که به دلیل عدم توانایی ما در سنجش بهره وری و کیفیت نرم افزار امکان تعیین مکان دقیق این خط فرضی ممکن نیست و عملا یک خود یک تصمیم مبتنی بر قضاوت تجربی است.
اصل موضوع را در اینجا بخوانید.
+ نوشته شده در یکشنبه 13 بهمن1387ساعت 16:21 توسط علی نوبر
|
بالاخره پس از حدود دو سال مجوز ورود به سرزمین کانگوروها را دریافت کردم. اگر همه چیز روی روال باشد از حدود ۲ ماه دیگر از آن سر دنیا مطالب را درج خواهم کرد.
+ نوشته شده در شنبه 12 بهمن1387ساعت 16:17 توسط علی نوبر
|
+ نوشته شده در یکشنبه 6 بهمن1387ساعت 15:46 توسط علی نوبر
|
