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

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

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

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

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

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

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

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

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

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

Ward Cunningham

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

«با عرض سلام
عکسی رو که ضمیمه کردم، گروهی از بچه‌های جهاد دانشگاهی کرمانشاه هستیم در حال انجام پروژه درس مهندسی نرم‌افزار دوره کارشناسی.
ما در این ترم دو گروه 15 نفری تشکیل دادیم و بر اساس کتاب شما پروژه مهندسی نرم افزار رو پیش بردیم
در عکس بچه‌ها در حال سناریو نوشتن هستن و حقیر که این ایمیل رو برای شما ارسال کردم در عکس نیستم! ….

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

عکس تکنیک طوفان فکری رو هم ضمیمه می‌کنم، مربوط به یکی از پروژه‌هاست که پایگاه اطلاعاتی فیلم و سینماست
ما خیلی از نیازمندی‌ها رو با این روش استخراج کردیم
این عکس رو از تخته وایت برد کلاس گرفتیم و پشت دوربین اعضا، هم خانم‌ها و هم آقایان نشستن و ایده‌هاشون مطرح می‌کنن

…….
در راه طلب مرد به همت باید
…….

قطع این مرحله بی همرهی خضر مکن ظلمات است بترس از خطر گمراهی
با تشکر

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

بهزاد علی محمدزاده
دانشجوی کارشناسی نرم افزار جهاد دانشگاهی کرمانشاه»

گزیده:
«تردیدها به ما خیانت می‌کنند، ما را از تلاش به دور می‌سازند و از پیروزی‌هایی که به احتمال زیاد نصیب ما خواهد شد محروم می‌سازند»
منسوب به ریچارد فاینمن