پیش گفتار

همان طور که قبلاً گفته شد در راستای تولید محتوای فارسی برای موضوعات مورد علاقه و باارزش، مطالب برگزیده پس از ترجمه توسط چند تن از عزیزان، از طریق وبلاگ در اختیار خوانندگان قرار خواهد گرفت. با وجود همه کمبودها، امیدوارم که این کار اثرگذار و مفید باشد.

مقدمه:
یکی از عباراتی که خیلی وقت‌ها می‌شنویم این است که: اینتراپت نده! (وقفه یا interrupt)
در فرهنگ لغت دهخدا، در شرح «وقفه» آمده است:
1ـ توقف، ایست، مکث، درنگ 2ـ توقف در حرفی از کلمه 3ـ فراغت، فرصت

interrupt در اینجا بدین شکل تعریف شده است:

1. To break the continuity or uniformity of: Rain interrupted our baseball game.
2. To hinder or stop the action or discourse of (someone) by breaking in on: The baby interrupted me while I was on the phone.

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

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

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

موضوع:
به تازگی مطلبی در این زمینه مطالعه کردم با عنوان Programmer Interrupted که بسیار آموزنده بود. اگر علاقه‌مند هستید می‌توانید آن را در اینجا مطالعه فرمایید.
خوشحال خواهم شد که از آموخته‌ها و تجربه‌های خود برایم بنویسید.

گزیده:

“Don’t interrupt me while I’m interrupting.”
Winston Churchill

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

تغییر نیازمندها
غول [بزرگ‌ترین و ترسناک‌ترین] مشکلات بسیاری از روشهای توسعه نرم‌افزار، فقط در حد یک مشکل ساده در XP است. با به کارگیری دستورالعمل «انجام طراحی فقط برای مسأله‌های امروز»، سیستمی که بر اساس XP در حال ساخت است، روز بعد برای پیمودن هر مسیری آمادگی دارد. انجام کارهای مشابه با کارهای قبلی، به دلیل ماهیت تکنیک بازسازی( Refactoring) در برآورده کردن اصل «یک بار و فقط یک بار»، ساده تر خواهد بود. لازم به یادآوری است که کارهای مشابه در یک پروژه زیاد است. با این حال، با اعلام یک نیازمندی اساسی و متفاوت-نامشابه-، برای انجام آن مجبور نیستید پای‌بند بسیاری از مکانیزمهای قبلی باشید.
در ابتدا درکی از میزان توانایی XP برای مواجهه با تغییر نیازمندی‌ها نداشتم. در اولین نسخه XP، تعیین این که هر داستان در کدام تکرار انجام شود، بخشی از برنامه‌ریزی انتشار(Release Planning) بود. تیم به مرور به این نتیجه رسید که می‌توان با کاهش زمان برنامه‌ریزی به نتایج بهتری دست یافت؛ کافی است از مشتری بخواهید فقط داستانهای تکرار جاری را انتخاب کند. در این روش، با شناسایی هر داستان جدید، نیازی نیست ترتیب داستانهای موجود در تکرارهای باقی‌مانده را بهم ریخته و دوباره مرتب کنید تا تکرار انجام داستان جدید مشخص شود. تنها کاری که باید انجام دهید، قراردادن داستان جدید در بین داستانهای انجام‌نشده است. یک یا دو هفته بعد، اگر داستان جدید هنوز هم برای مشتری اهمیت داشته باشد، وی آن را برای انجام در تکرار پیش‌رو انتخاب خواهد کرد.
(مترجم:
فرض کنید که در سه تکرار پیش رو، قرار است داستانهای زیر انجام شود(اندازه هر داستان جلوی آن مشخص شده است). سرعت تیم برای هر تکرار را 7 فرض کنید.
تکرار 1:
داستان A‏ = 3 داستان B‏ = 4
تکرار 2:
داستان C‏ = 5 داستان D‏ = 2
تکرار 3:
داستان E‏ = 2 داستان F‏ = 3 داستان G‏ = 2

حال اگر داستان Z با اندازه 2 به تازگی شناسایی شود و مشخص گردد باید که بعد از داستان A انجام شود، ترتیب انجام داستان‌ها و تکرارهای متناظر آنها دچار تغییر می‌شود که در زیر نمایش داده شده است. این تغییر فقط یک جابه‌جایی ساده نیست، بلکه واقعاً به‌هم ریختن داستان‌ها و مرتب‌سازی دوباره است(به ترتیب حروف الفبای انگلیسی در بالا و پایین دقت کنید).
تکرار 1:
داستان A‏ = 3 داستان Z‏ = 2 داستان D‏ = 2
تکرار 2:
داستان B‏ = 4 داستان F‏ = 3
تکرار 3:
داستان C‏ = 5 داستان E‏ = 2
تکرار 4:
داستان G‏ = 2
)

این روش برنامه‌ریزی که در آن هر بار فقط تکرار بعدی برنامه‌ریزی می‌شود، موجب خودمانایی (self-similarity) مطلوبی می‌گردد. بدین شکل که در بازه‌ ماهانه و سالانه، با دو دسته داستان روبرو هستید: داستانهای انتشار جاری و داستانهای باقی‌مانده برای انتشارهای بعدی. در بازه هفتگی و ماهیانه نیز با دو دسته داستان روبرو هستید: داستانهای تکرار جاری و داستان‌های باقی‌مانده از انتشار جاری. در بازه روزانه و هفتگی هم با دو دسته کار(وظیفه) سروکار دارید: کارهای در دست انجام و کارهای باقی‌مانده از تکرار جاری. همچنین در بازه دقیقه و روزانه نیز با دو دسته مورد آزمون روبرو هستید: موردهای آزمون در دست انجام و موردهای آزمون باقی‌مانده.

Ron Jeffries

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

گزیده:
روياهاي كوچك نداشته باشيد، چون آن‌ها قدرت حركت دادن قلب انسان را ندارند.
يوهان ولفگانگ فان گوته

تصویر زیر برگرفته از سایت اتحادیه چابک(agile alliance) است. در این تصویر، تجربه‌های(practices) متدهای چابک در قالب دسته‌هایی به نمایش گذاشته شده است.
هر بار که به این تصویر نگاه می‌کنم، زیبایی و سادگی‌اش تحسین مرا برمی‌انگیزد. شاید این احساس ناشی از شباهت این تصویر با نقشه متروی تهران باشد!

برای مشاهده تصویر بزرگتر روی آن کلیک کنید.

گزیده:
مرد خردمند هنر پیشه را
عمر دو بایست در این روزگار
تا به یکی تجربه آموختن
با دگری تجربه بردن به کار.
سعدی

ضمن سپاس از آقای مجید آواژ، نوشته زیر به نقل از ایشان در روزنوشت‌های بهساد آورده شده است.
“

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

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

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

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

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

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

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

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

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

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

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

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