«محمدرضا حدادی متولد مردادماه ۱۳۵۳ در تهران
….
در رشته مهندسی کامپیوتر گرایش نرم افزار در دانشگاه علم و صنعت در سال ۱۳۷۱ قبول شدم و در سال ۱۳۷۵ نیز در کنکور کارشناسی ارشد نرم افزار در دانشگاه صنعتی شریف پذیرفته شدم. هم اکنون نیز در حال تحصیل رشته MBA هستم.

کار خود را در فناوری اطلاعات از سال ۱۳۷۲ آغاز نمودم ابتدا در دو شرکت به عنوان برنامه نویس رفتم و چند پروژه شخصی نیز انجام دادم. سپس در سال ۱۳۷۳ وارد شرکت جهان گرافیک کامپیوتر شدم. در این شرکت پروژه های بزرگ و موفقی را انجام دادم. در سال ۱۳۷۶ وارد بانک صنعت و معدن شدم و پروژه تسهیلات مالی بانک صنعت و معدن را راه اندازی کردم سپس در سال ۱۳۷۷ به همراه تنی چند از دوستان اقدام به خرید شرکت جهان گرافیک کامپیوتر نموده و شرکت برید را با هدف عرضه سیستم های اتوماسیون اداری تاسیس نمودیم. از همان ابتدا عضو هیئت مدیره و مدیر فنی برید بودم تا درسال ۱۳۸۷به عنوان مدیرعامل وارد مسیری سخت و دشوار و طاقت فرسا شدم.

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

از طوفان که درآمدی دیگر همان آدمی نخواهی بود که به طوفان پا نهادی. معنی طوفان همین است.»

این متن، اولین نوشته وبلاگ جناب آقای مهندس حدادی، مدیر عامل محترم شرکت برید سامانه نوین است. نوشته‌های ایشان را می‌توانید در آدرس http://haddadi.baridsoft.ir پیدا کنید.

احتمالاً با وجود انبوه کارها، در وبلاگشان دیر به دیر خواهند نوشت، اما همیشه چشم انتظار نوشته‌هایشان خواهم بود. نتیجه سالها تجربه را در پس نوشته‌هایشان خواهم یافت.
برایشان بهترین‌ها را آرزومندم.

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

کم‌تر دیده‌ شده که کارفرمایی برای سپاسگزاری و جبران زحمات پیمانکار نرم‌افزاری‌اش به وی پاداش دهد. کم‌تر هم دیده شده که پیمانکاری چنان رضایت کارفرمایش را جلب کند که وی چنین کند.

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

ایشان نوشته‌اند:
“دلایل پرداخت مبلغ پاداش :
1-مشارکت فعال در بحث های تحلیلی و ایده‌پردازی
2-کیفیت بالای تولید محصول از لحاظ خطا و پیاده‌سازی دقیق مطالب خواسته شده
3-دقت و وسواس برروی رساندن به موقع محصول حسب توافقات انجام شده
4-انجام موارد خلاقانه به سامانه که لزوما در بحث‌ها به میان نیامده است (موضوع کانبان)”

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

گزیده:
ندارد.

“جابز یکی از افراد سرشناس و موفق دنیای کامپیوتر و کسب و کار است. بیشتر افرادی که در این حوزه فعالیت می‌کنند سعی دارند از او بیاموزند. لری پیج یکی از موسسان گوگل نیز زمانی که استیو جابز زنده بود سعی کرد یک ملاقات حضوری با استیو داشته باشد. در این ملاقات جابز ۳ نکته را گوشزد کرد.

۱. گوگل باید نقاط قوت خود را یافته و بر روی آنها تمرکز کند.

۲. لری به عنوان یک مدیرعامل باید به دنبال افراد شاخص (A-Players) باشد و با کسانی که ارزش افزوده‌ای برای شرکت ندارند زیاد هم مهربان نباشد.

۳. جابز به پیج گوشزد کرد که همانند مایکروسافت به دنبال تولید محصول برای دسته‌بندی‌های مختلف نباشد زیرا به مرور زمان تمرکز بر روی توانایی‌های اصلی از دست خواهد رفت. “

به نقل از:سایت جالب و خواندنی آی کلاب

گزیده:
اپل روزگار سختی گذرانده که هنوز از آن کاملا خلاص نشده‌است. اما ما می‌خواهیم اوضاع را عوض کنیم، زیرا هنوز در شرکت نیروهایی داریم که شور، استعداد و مهارت دارند. و مشتریانی داریم که شور، استعداد و مهارت دارند. و برنامه‌نویسانی هم داریم که شور، استعداد و مهارت دارند و مدام مهارت خود را بهبود می‌بخشند. من آدم محصول‌باوری هستم، به این معنی که فکر می‌کنم که اگر محصول درجه‌یکی به مردم ارائه کنید آن‌ها استقبال خواهند کرد. چیزی که می‌توانم به شما بگویم این است که ما محصولات درجه‌یکی در دست تولید داریم.»
استیو جابز، ۱۹۹۷، – سال برگشت جابز به اپل

مترجم: آقای مهندس مهدی نگاهی

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

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

همکاری نکردن مشتریان
با مشتری‌ای که در بازی شرکت نمی‌کند – مشارکت نمی‌کند- چه می‌کنید؟ هیچ آزمونی را مشخص نمی‌کند، در مورد الویت‌ها تصمیم نمی‌گیرد، داستان‌ها را نمی‌نویسد.
ابتدا با کامل کردن تدیجی نرم‌افزار طی چندین تکرار و فراهم‌سازی امکانی برای کنترل بر توسعه توسط مشتری، سعی کنید رابطه‌ای مبتنی بر اعتماد با وی برقرار کنید. اگر اعتماد شروع به کم شدن کرد و اشکال از شما بود، راه حلی برای آن پیدا کنید. ببینید می‌توانید کاری برای بهبود ارتباط انجام دهید یا خیر؟
اگر به تنهایی نتوانستید مشکل را حل کنید، باید از مشتری درخواست کمک کنید. برنامه‌نویسان XPبه سادگی و بر اساس حدس و گمان خود، کار را پیش نمی‌برند. نتایج به دست آمده را به مشتری توضیح دهید. اگر تغییری در آنها به وجود نیامد، نگرانی‌های خود را آشکارا بیان کنید. اگر کسی به نگرانی‌های شما و حل مشکل توجهی نکرد، احتمالاً ادامه پروژه خیلی برایشان اهمیت ندارد.

Ward Cunningham

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

گزیده:
چرا بعضی آدمها برای آن که خودشان را «ثابت» کنند، دیگران را «متغیر» می‌کنند؟

متغیر: آشفته و ناراحت

برای اطلاعات بیشتر مراجعه شود به اینجا

گزیده:
«هیچکس از پیش خود چیزی نشد
هیچ آهن خنجر تیزی نشد
هیچ قنادی نشد استادکار
تا که شاگرد شکرریزی نشد»

مرجع: ویکی گفتاورد

مترجم: آقای مهندس مهدی نگاهی

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

برخی از متدولوژی‌ها مانند Cleanroom، برنامه‌نویسان را از آزمایش و بعضی مواقع حتی از کامپایل برنامه خود منع می‌کنند. فرایند معمولی بدین گونه است که برنامه‌نویس کدی را می‌نویسد، آن را کامپایل می‌کند، مطمئن می‌شود که درست کار می‌کند و سپس آن را به واحد سازمانی مسئول آزمون می‌فرستد. سپس آزمایش میزکار^۱ (bench test) در یک مرحله‌ روی همه کد انجام می‌شود. در این آزمایش، متغیرهای کد بررسی می‌گردند، خروجی دستورات چاپی تفسیر و کنترل می‌شوند و چندین دکمه فشار داده می‌‌شود تا چک لیست آزمون‌ تکمیل و تأیید گردد.

استراتژی آزمون XP نیاز به کار بیشتری نسبت به استراتژی‌های آزمایش میزکار ندارد. در واقع XP فقط شکل انجام آزمون‌ها را تغییر داده است. به جای انجام فعالیت‌هایی که نتایج آنها در پایان مانند اتر محو می‌شوند، آزمون‌ها به شکل دائمی ذخیره می‌شوند. این آزمون‌ها به صورت خودکار امروز اجرا می‌شوند و بعد از ظهر، فردا، هفته آینده و سال آینده بعد از بکپارچه‌سازی نیز اجرا خواهند شد. اطمینان ناشی از اجرای آزمونها به تدریج و با زیاد شدن آنها افزایش می‌یابد و از این رو تیم XP به مرور زمان، به سیستم اطمینان پیدا می‌کند.

همانطور که قبلا اشاره شد، آزمون‌ها توسط مشتریان نیز تعیین می‌شوند. مشتریان در ابتدای هر تکرار اعلام می‌کنند که در چه صورتی خواهند پذیرفت که داستان‌های کاربر به درستی پیاده‌سازی شده‌اند. نظرات مشتریان به آزمون سطح سیستم (system-wide test) تبدیل می‌شود. تبدیل می‌تواند مستقیماً توسط خود مشتری با استفاده از زبانهای اسکریپتی متنی یا گرافیکی یا توسط برنامه‌نویسان با استفاده از ابزارهای آزمون انجام شود. این گونه آزمون‌ها نیز موجب افزایش اطمینان به سیستم می‌شوند با این تفاوت که اطمینان مشتری را نسبت به عملیات درست سیستم افزایش می‌دهند[آزمونهای واحد اطمینان برنامه‌نویسان را افزایش می‌دهند].

۱- آزمایش میزکار: آزمایشی که روی ماشین، قطعه یا نرم‌افزار، قبل از تحویل آن برای استفاده با هدف کسب اطمینان از درستی آن انجام می‌شود.

پانوشت: آقای مهندس نگاهی عزیز برای ادامه تحصیل به کشور کانادا نقل مکان کرده‌اند. بهترین شادباش‌ها تقدیم ایشان باد. امیدوارم همواره شاد، تندرست و پیروز باشند.

گزیده:
«در حکومت سه عمل مختلف است: تهیه، مشورت، اجرا؛ اگر می‌خواهی کار سریع‌تر انجام بگیرد برای مرحله تهیه و اجرا اشخاص کم برگزین اما مرحله مشورت و آزمایش را به عهده اشخاص متعدد واگذار کن.»
فرانسیس بیکن