حضرت مولانا می‌فرماید:
اختلاف خلق از نام اوفتاد
چون به معنی رفت آرام اوفتاد

استاد گرانمایه، انسان دوست‌داشتنی و آموزگار دانا، استاد روحانی رانکوهی در یکی از کلاسهای پایگاه داده روی تابلو نوشت: پایگاه داده. سپس ادامه داد، دانشجویان عزیز، این زبان «مادری» است. در گوشه‌ دیگری از تابلو نوشت: Database. باز ادامه داد، عزیزانم این زبان «مادرجانی». زبان مادرجانی از زبان مادری عزیزتر است- به واسطه پسوند «جان».

آن روز همه خندیدیم و همه می‌دانستیم که استاد به زبان فارسی در متون فنی بسیار پای‌بند است.

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

با نزدیک شدن آغاز دوره‌ متدهای چابک(Agile Methods) از یک سو و ترجمه برخی متون مرجع، لزوم این کار بیش از پیش آشکار شد. از این رو با هدف یک‌دستی معادلهای فارسی اصطلاحات چابکی، کاری را شروع کرده‌ام. اگز عزیزی علاقه‌مند به همکاری است، لطفاً اعلام نماید تا کار سریع‌ و درست‌ پیش رود. آرزو دارم که نتیجه کار، عالی و قابل استفاده باشد.
گزیده:

“Translation is not a matter of words only: it is a matter of making intelligible a whole culture.” Anthony Burgess

تازه‌کار: سلام
چابک: سلام

تازه‌کار: امروز می‌خواهم یک سوال شخصی از شما بپرسم. این پرسش با خواندن این مطلب برایم پیش آمده است.
چابک: بفرمایید.
تازه‌کار: چرا شما به متد خاصی اشاره نمی‌کنید و مدام کلمه چابک را به کار می‌برید.
چابک: مثلاً کدام متد؟
تازه‌کار: مثلاٌ اسکرام.
چابک: متوجه شدم. اجازه دهید کمی درباره آن توضیح دهم.
در گردهمایی سال 2001 که منجر به بیانیه چابک شد، همه شرکت‌کنندگان در مورد اولین موضوعی که توافق داشتند این بود که: ما به دنبال تجمیع و تلفیق متدها برای ایجاد چیزی به نام متدولوژی سبک یکپارچه-(Unified Light Methodology” (ULM- نیستیم. بعد از حدود یازده سال از آن زمان، چیزی که پیشروان متدها بدان تأکید می‌کنند این است که ما واژه مشترکی به نام “چابکی” داریم و نه یک متد خاص.
اجازه دهید مثالی عرض کنم:
کیفیت طراحی یکی از موضوعات تاکید شده در متدهای چابک است. متد DSDM با به‌کارگیری مجموعه‌ای از نمونه‌سازی‌ها(Prototype) به حوزه‌های ناشناخته یا ناپایدار تکنولوژی، کسب‌وکار و رابط کاربری حمله می‌کند. Scrum با استفاده از جلسات کوتاه روزانه و بازنگری‌های جامع انتهای Sprint استفاده می‌کند. XP از تکنیکهای Spike و TDD کمک می‌گیرد و …. اینها نمونه‌هایی از تکنیکهایی هستند که در این متدها وجود دارند.
چرا باید فقط به یک یا دو متد بسنده کنیم و آموزه‌هایشان را یاد نگیریم و به کار نبندیم؟ چابکی تاکید فراوانی بر سازگاری و تطابق با محیط دارد. در هر شرایطی، روش تطبیق‌پذیری و سازگاری متفاوت خواهد بود. یادگیری آموزه‌های همه متدهای چابک، کمک خواهد کرد تا انتخاب مناسبی برای جااندازی آنها داشته باشیم.

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

بگذارید مثالی دیگری عرض کنم.
طول دوره هر تکرار یکی از موضوعات مهم در روشهای تکراری(iterative) و از جمله متدهای چابک است. تعداد روزهای پیشنهادی برای دوره تکرار در هر یک از متدهای چابک، عددهای متفاوتی است. کدام یک را به عنوان دوره تکرار انتخاب می‌کنید؟ تا وقتی چند انتخاب و چرایی هر یک از آنها را ندانید، فقط به همان یک انتخاب بسنده خواهید کرد.

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

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

چابک: اشکالی ندارد. جوانی است و هزار تا دردسر.

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

با این دیدگاه جاهایی نیاز به نظم و نظام (Discipline) خواهید داشت و متدهای چابک مسائل شما را حل نخواهند کرد و بر عکس، جلوی سازگاری و تطبیق‌پذیری شما را خواهند گرفت. در این شرایط ضروری است نگاهی به متدهای با نظام (Discipline based methods) داشته باشید و از تجربه‌ها و آموزه‌های آنها استفاده کنید.

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

دو تیم را به یاد می‌آورم که دو شیوه مختلف برای ورود به متدهای چابک انتخاب کرده بودند. یکی تاکید می‌کرد که می‌خواهد مبتنی بر Scrum کار کند و دیگری تاکید می‌کرد که می‌خواهد بهبود (Improvement) ایجاد کند. تیم اول ناخودآگاه به این سمت حرکت کرد که واو به واو متد Scrum را بر اساس نیازهایش اجرا کند. در حالی که تیم دوم، به فکر مشکلات و مسائل خود بود و برای رفع آنها، دنبال راه حل می‌گشت – منبع راه حل مهم نبود، حتی تجارب گذشته تیم -.
هر چند اشکال، به اجرا بر می‌گشت و اشکالی به متدها وارد نبود، اما ناخودآگاه، تیم به این گونه تفکرات – واو به واو اجرا کردن متدها و بسته‌شدن تفکر و خلاقیت- متمایل می‌شود و گریز از آن دشوار است.

تازه‌کار: وقت به پایان رسیده است. آیا می‌توانید مرجعی برای موضوع گفت‌وگوی بعدی معرفی کنید.

چابک: قطعاً.
پیشنهاد می‌کنم که دو مرجع اصلی چابکی را مطالعه کنید. یکی از بین توسعه‌دهندگان بیرون آمده و دیگری از مدیران پروژه و رهبران تیمها. اولی بیانیه چابک (Manifest for Agile Software Development) و دیگری اعلامیه وابستگی متقابل (Declaration of Interdependence) است.

تازه‌کار: سپاسگزارم.

چابک: من هم همین طور. تا دیداری دیگر، بدرود.

گزیده:

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

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

——————————
به جلسه‌ای دعوت شده‌ام. مدیران میانی شرکت دور هم گرد آمده‌اند تا در مورد موضوع مهمی صحبت کنند. همه مشغول بحث و گفت‌وگو هستند.
یکی به ناگاه می‌گوید که انجام این بخش از کار را به فلانی – یکی از افراد با تجربه و کاردان شرکت- بسپریم.
دیگری می‌گوید: او را جزو آمار نیار.
با تعجب می‌پرسم: چرا؟
می‌گوید: او تا چند وقت دیگر به ..[یک کشور] می‌رود.
خیلی متعجب نشدم، چرا که اگر نگویم همه، اما اغلب عزیزانی که می‌شناسم در صف مهاجرت هستند. فقط زمان رفتن، نامعلوم است.
آن چه ذهنم را مشغول کرد، این بود که ظرفیت کاهش یافته شرکت، چقدر طول می‌کشد، به اندازه قبلی برگردد؟ در این مدت، چقدر فرصتها از دست خواهد رفت؟ چقدر کارها، عقب خواهد افتاد؟
برایش یافتن آن چه که آرزویش را داشت، آرزو می‌کنم.

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

——————————-
روزی دوستی که مسئولیتی در شرکتی داشت و از مهاجرت کارمندانش به شدت مستأصل و بیچاره شده بود، به شوخی گفت: اگر روزی پروسه مهاجرت کوتاه شود، بیچارگی‌ام پایان می‌یابد، چرا که کارمندی نخواهم داشت که بدانها فکر کنم.

گزیده:
من
رویایی دارم، …
رویای یک رقص بی‌وقفه از شادی
یغما گلرویی

What is Code Decay?
Code decay occurs when a software system becomes increasing difficult to maintain. The design and code of the system become more complex, making changes to the system becomes noticeably more difficult, more costly in time and resources, and more prone to regression errors. Code decay can result in a system that is more expensive to maintain because the number of errors introduced by a single change in the system (regression) steadily increases. In the worst case, a single change can – on average – introduce one or more regression errors into the system.

How Does Code Decay Occur?
Code decay occurs simply by touching the code. The more code is touched – as measured by changes to the files where the code resides – the higher the amount of code decay. This is true on average across the collection of files. Code decay happens because code tends to increase in complexity the more it’s modified. Files that have been modified the most are usually the most complex, thus most likely to suffer from code decay.

How Can Maintenance Slow Down Code Decay?
Refactoring reduces code decay. Refactoring is a set of techniques for simplifying code without changing what it does.

Reference: IBM RUP for Maintenance

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

داشتم ارائه آقای مایک کوهن را در اینجا می‌دیدم.

A Reusable Scrum Presentation (An Introduction to Scrum)
This scrum presentation is a 90 minute introduction to Scrum that is fully redistributable and reusable. It can be used to introduce Scrum to your user group or organization.
This is a completely updated, much fancier version of this popular scrum presentation file that has been available for download since 2002.

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

با خود گفتم چه خوب خواهد شد اگر بتوانم این ارائه را به کمک دوستان و عزیزانم به فارسی ترجمه و به این فهرست اضافه کنم. هم فال خواهد بود و هم تماشا.

پس شروع کردم!

در کنار همه مزیت‌ها، این گونه کارها، وقتهایی را که نمی‌توان به کارهای دیگری اختصاص داد (رفت و آمد، انتظارهای قبل از جلسات، …) را پربار می‌کنند.

گزیده:
«به خاطر داشته باش که فقط یک «زمان» از همهٔ وقت‌های دیگر مهم‌تر است و آن «هم‌اکنون» است.» لئو تولستوی

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

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

بروکس در دهه 1950، کونستانتین در دهه 1990 و فارسر در OOPSLA سال 94 به آن اشاره کرده‌اند. اما شهرت آن به سال 1999 با کتاب XP Explained از کنت بک و سایرین برمی‌گردد.

نکته جالب توجه این است که این تکنیک می‌تواند در تیم‌های غیرچابک نیز اجرا گردد.

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

موقع خواندن مقاله وقتی به جمله زیر رسیدم، نتوانستم جلوی خنده‌ام را بگیرم:

“People who have been pairing a while, they’ll start acting like old married couples,” said Marc Phillips.

مقاله را می‌توانید اینجا مطالعه کنید.
گزیده:

“A good programmer is someone who looks both ways before crossing a one-way street. “
– Anonymous