برای ثبت نام، لطفاً به اینجا مراجعه فرمایید.

فیلیپ کراچن در وبلاگ مطلبی نوشته است با نام Friction.

By analogy, in software development, friction is the set of phenomena that limits or constraints our progress, therefore reduces our velocity (or productivity).

مترجم: مهندس علیرضا اسماعیلی

بخش اول
بخش دوم
بخش سوم
بخش چهارم
بخش پنجم
بخش ششم
بخش هفتم

ادامه ....

مترجم: مهندس علیرضا اسماعیلی

بخش اول
بخش دوم
بخش سوم
بخش چهارم
بخش پنجم
بخش ششم

ادامه ....

مترجم: مهندس شهاب‌الدین فرحبخش

بخش اول
بخش دوم
بخش سوم
بخش چهارم
بخش پنجم

ادامه ....

مترجم: خانم مهندس فاطمه اردستانی

بخش اول

ادامه ....

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

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

مجموعه جدید مقاله‌ها، به حوزه نیازمندی‌ها در متدهای چابک اختصاص داده شده است. مرجع فعلی مطالب، کتاب  Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise  نوشته‌ی Dean Leffingwell است.

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

مترجم: مهندس شهاب‌الدین فرحبخش

ادامه ...
واژه مناسب برای توصیف نتیجه‌ی برنامه‌ریزی اسکرام چیست: پیش‌بینی یا تعهد؟ ....

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

دوستان گرامی عضو انجمن چابک ایران به سرپرستی جناب آقای مهندس صفری کار بزرگی انجام داده و کتاب «اسکرام و کانبان در کنار هم» (Kanban and Scrum - making the most of both) را به فارسی برگردانده‌اند.

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

- جناب آقای اسد صفری
- جناب آقای آرش میلانی
- جناب آقای رضا فرشی
- جناب آقای سهیل صمدزاده
- جناب آقای سینا استاد‌هاشم
- جناب آقای صادق ترکمن
- جناب آقای علی مقدم
- سرکار خانم فاطمه کروبی
- جناب آقای هادی نیکوئی
- جناب آقای محمود متین‏فر

کتاب را می‌توانید از اینجا دانلود فرمایید و درباره‌اش در اینجا بیشتر بدانید.

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

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

تغییر نیازمندها
غول [بزرگ‌ترین و ترسناک‌ترین] مشکلات بسیاری از روشهای توسعه نرم‌افزار، فقط در حد یک مشکل ساده در 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 برای تیم خود را مدیریت کنید و در کنار تغییر فرایند، تحویل محصول نیز دچار مشکل بیشتری نشود.

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

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

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

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

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

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

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

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

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

 سمینار برنامه­ریزی چابک (Agile Planning)

«Plans are nothing; planning is everything.»

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

این متدها به دنبال چابکی در توسعه نرم­افزار هستند، از این رو انتظار می­رود که برنامه­ریزی نیز در آنها چابک باشد. به عبارت دیگر به جای «برنامه­ریزی پروژه­های چابک» به دنبال «برنامه­ریزی چابک پروژه­ها» هستند. اما چگونه؟ این سمینار به این پرسش پاسخ خواهد دهد.

اجرای متدهای چابک دشوار است. دشواری به دلیل کارهایی نیست که در آنها انجام می­شود، بلکه ناشی از کارهایی است که در آنها انجام نمی­شود. مگر می­شود مدیر پروژه­ای را بدون داشتن ابزار گانت چارت تصور کرد؟ در این سمینار به چگونگی اجرای برنامه­ریزی، کنترل و پایش چابک پروژه­ها نیز پرداخته می­شود.

سرفصل مطالب سمینار عبارتند از:
تغییر پارادایم در مدیریت پروژه: ارزشهای رهبری چابک
برنامه­ریزی چندسطحی و کاربردهای آن در برنامه­ریزی چابک
برنامه­ریزی محصول، انتشار، تکرار و روزانه در متدهای چابک
رویکرد و تکنیکهای براورد پروژه­های چابک
ابزارهای برنامه­ریزی، کنترل و پایش

زمان و مکان برگزاری:
چهار شنبه مورخ 29/09/1391
ساعت 15:00 الی 18:00
تهران خیابان سهروردی شمالی، خیابان خرمشهر(آپادانا)، خیابان شهید عربعلی(نوبخت)، کوچه نهم، شماره 13، سازمان نظام صنفی رایانه ای کشور. تلفن:88734499، سرکار خانم محمدلو

هزینه و نحوه ثبت­نام:
....
....
به شرکت­کنندگانی که مشخصات ثبت نام را تا 27 آذرماه ارسال نمایند، در پایان سمینار، گواهینامه اعطاء خواهد شد.

گزیده:
ساده ترين كار جهان اين است كه خود باشي و دشوارترين كار جهان اين است كه كسي باشي كه ديگران مي‌خواهند. هربرت اتو
مرجع: اس.جی.

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

----------------------
پانل تخصصی: 
بررسی روش مناسب برای تولید نرم‌افزار در ایران (مقایسه روش‌های پرتشریفات با چابک)
با حضور آقای دکتر مازیار چیت‌ساز و مهندس یوسف مهرداد بی‌بالان
چهارشنبه 22 آذر 2 عصر
سالن 40 غرفه 21

گزیده:
بيست سال بعد، بابت كارهايي كه نكرده‌اي بيشتر افسوس مي‌خوري تا بابت كارهايي كه كرده‌اي. بنابراين، روحيه تسليم پذيري را كنار بگذار، از حاشيه امنيت بيرون بيا، جستجو كن، بگرد، آرزو كن و كشف كن. مارك تواين
مرجع: اس.جی.

I Don't Care About "Agile"

 All ideas are great, until they are confronted with reality.

The concept of Management By Objectives by Peter F. Drucker was great, except for the fact that it didn’t take into account that managers could easily abuse it to enrich themselves with big bonuses.

The idea of Shareholder Value, supported by Nobel-prize winner Milton Friedman, was great in theory and perfect for rational minds, as long as we ignored the fact that economic decisions are almost never rational.

The Balanced Scorecard by Kaplan and Norton is a very good tool for managers. But most managers think they’re driving their organization like a machine, instead of riding it as if it’s a horse, and digital dashboards don’t sit well on horses.

The list of failed management ideas goes on an on…

Now we are in the age of Agile Management, Lean Development, and Complexity Thinking, with Scrum, Kanban, and Cynefin trying to ride the waves. And the first signals of disillusion have already been heard. I hear, “It’s not working here”, “People don’t want to change” and “These are fads like all the others”.

And yes… they may be right.

If you don’t change the culture of your organization to one of learning instead of controlling, if you don’t see your business as a community instead of a computer, and if you don’t focus on improving through people rather than processes, you will get exactly that. The ideas won’t work, people won’t change, and it’s all just a fad.

No great idea survives contact with the ignorant.

Of course, words like Agile and Lean were conceived to try and change the mindsets of managers and the cultures of businesses. But if these words don’t succeed, we shouldn’t mourn their defeat. The Agile and Lean brands may be destined to end up on the same pile of discarded words as all the others. Not because the ideas weren’t any good. But because they couldn’t cope with the real world.

I don’t care.

My goal is not to define, use, and protect the word Agile.

My goal is to be happy while learning new things and creating value in a network with other people. I will use any cool words that can help me with this. And right now, I’m an optimist. For me, Agile is still an awesome brand.

Until it isn’t.

Reference: www.noop.nl

منبع: از میان نامه‌های محسن

Quote:
Having a style is like being in jail.
Anthon Beeke

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

وظیفه (Task)
برای پیاده‌سازی هر وظیفه، برنامه‌نویسِ مسئول ابتدا باید یک همکار پیدا کند، زیرا همه کدهای برنامه به صورت دو نفره پشت یک کامپیوتر نوشته می‌شود. اگر پرسشی در مورد محدوده یا روش پیاده‌سازی به وجود آید، دو همکار(برنامه‌نویس و همکار وی) جلسه کوتاهی (15 دقیقه‌ای) با مشتری، برنامه‌نویسان مرتبط یا هر دو برگزار می‌کند. برنامه‌نویسان مرتبط کسانی هستند که دانش بیشتری در مورد کدی دارند که در طول پیاده‌سازی وظیفه تغییر خواهد کرد.

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

 وقتی مورد آزمونی وجود دارد که اجرا نمی‌شود:
+ یا یک راه تمیز برای اجرای مورد آزمون پیدا شده، که در این صورت همان راه پیش برده می‌شود؛

+ یا یک راه ناپسند برای اجرای مورد آزمون پیدا شده، اما راه تمیزی هم وجود دارد که نیاز به تغییر طراحی فعلی دارد. در این حالت، سیستم بازسازی (Refactor) می‌شود تا راه تمیز قابل اجرا شود؛

+ یا یک راه ناپسند برای اجرای مورد آزمون پیدا شده و راه تمیزی حتی با بازسازی سیستم نیز متصور نیست. در این حالت، همان راه ناپسند پیش برده می‌شود تا مورد آزمون اجرا شود.

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

هدف این روش، حفظ تمرکز تیم در کار است. با این شیوه، می‌توان کار فعلی را به خوبی انجام داد و در عین حال بینش و درک کلانی از سیستم داشت. این بینش از تعامل زیاد با کد ناشی می‌شود.

گزیده:
مابک(کریستوفر پلامر): خدای من اینها دیگه کی‌یند؟
لوول(ال پاچینو): آدمهای عادی در یک شرایط غیرعادی. چه انتظاری داری مرد !
گفت‌وگویی از فیلم تماشایی Insider

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

گزیده:
هر هدفی بدون برنامه، فقط یک آرزوست.
آنتونیو دو سنت هگزوپری

بخش دوم ترجمه مقاله Embracing Change with Extreme Programming نوشته Kent Beck را می‌توانید در اینجا مطالعه نمایید.
مترجم: آقای مهندس مهدی نگاهی

انتشار (Release)
توجه کنید که مطابق شکل 2، همه داستانها در ابتدا پیاده‌سازی نمی‌شوند. بلکه مشتری کوچکترین مجموعه از با ارزش‌ترین داستانهایی را انتخاب می‌کند که در کنار هم معقول و منطقی هستند. ابتدا این مجموعه از داستانها پیاده‌سازی شده و در محصول نهایی قرار می‌گیرند و سپس باقی‌مانده‌ها پیاده‌سازی می‌شوند.

انتخاب داستانهای هر انتشار تا حدودی شبیه خرید مواد غذایی از فروشگاه است. وقتی با 100 دلار به فروشگاه  می‌رویم، به خریدهای ضروری(با الویت) فکر می‌کنیم، به قیمت اجناس نگاه می‌کنیم و بعد تصمیم می‌گیریم که چه چیزهایی خریداری کنیم. [در اینجا بودجه موجود برای خرید -100 دلار- قابل افزایش نیست. رویکرد دیگر این است که ابتدا اجناس ضروری انتخاب می‌شوند و بعد بودجه لازم برای خرید آنها با جمع قیمتها، براورد می‌شود-مثلاً 150 دلار-].

در بازی برنامه‌ریزی(فرایند برنامه‌ریزی XP)، داستانها معادل اجناس و برآورد هر داستان معادل قیمت است[به عنوان مثال اگر براورد پیاده‌سازی داستانی، 3 نفر-روز باشد، یعنی قیمت آن 3 واحد است]. بودجه با اندازه‌گیری خروجی تیم  محاسبه می‌شود که مبنای آن جمع  برآورد داستانهای انجام شده در واحد زمان است.

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

 تکرار(Iteration)
هدف هر تکرار، افزودن داستانهای جدیدِ آزمایش شده و آماده‌ی استفاده به محصول است. فرایند با طرحی شروع می‌شود که در آن داستانهای انتخاب شده برای پیاده‌سازی و چگونگی انجام آنها توسط تیم مشخص شده است. هنگامی که تیم در حال پیاده‌سازی است، مشتری آزمونهای کارکردی (functional tests) را مشخص می‌کند. آزمون‌ها در پایان تکرار اجرا شده و تیم برای تکرار بعدی آماده می‌شود.

برنامه‌ریزی تکرار با درخواست دوباره از مشتری برای انتخاب باارزش‌ترین داستان‌ها آغاز می‌شود با این تفاوت که این‌بار، داستانها از بین داستانهای باقی‌مانده از انتشار انتخاب می‌شوند. داستان‌ها توسط تیم به مجموعه‌ای از وظایف (tasks) شکسته می‌شوند –وظیفه کاری است که یک نفر می‌تواند طی چند روز انجام دهد. در صورت وجود وظایف  فنی– مانند ارتقاء (upgrade) پایگاه داده به نسخه جدید-، آنها نیز به لیست وظایف افزوده می‌شوند.

 پس از آن، برنامه‌نویسان برای پذیرش انجام وظایف، اعلام آمادگی می‌کنند. وقتی گفت‌وگو درباره وظایف به پایان می‌رسد، برنامه‌نویس مسئول، زمان انجام وظیفه‌‌اش را بر مبنای روز ایده‌آل (ideal day) برآورد و اعلام می‌کند[روز ایده‌آل یکی از واحدهای براورد اندازه(سایز) داستان است. روز ایده‌ال مدت زمان انجام یک کار است به شرطی که مجری فقط همان یک کار را انجام دهد، وقفه‌ای در انجام کار به وجود نیاید و منابع لازم برای کار نیز فوراً آماده گردد].

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

برنامه نویسان وظایف خود را طی تکرار انجام می‌دهند. با پایان یافتن هر وظیفه، برنامه‌نویس کد نوشته شده را با کد سیستم یکپارچه کرده و آزمون‌ها را اجرا می‌کند. همه آزمونها باید اجرا و پشت سر گذاشته شوند، در غیر این صورت کدها اجازه یکپارچه‌شدن با سیستم را نخواهند داشت.

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

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

بخش اول ترجمه مقاله Embracing Change with Extreme Programming نوشته  Kent Beck را می‌توانید در اینجا  مطالعه نمایید.
مترجم: آقای مهندس مهدی نگاهی  

آناتومی(کالبدشناسی) XP
XP مسیر فرایند رایج توسعه نرم‌افزار را تغییر می‌دهد. XP با استفاده از کاهش هزینه اعمال تغییرات نرم افزار، به جای انجام یک‌باره برنامه‌ریزی، تحلیل و طراحی برای آینده‌‌ای بسیار دور،  آنها را به صورت مستمر در تمام مدت توسعه و  در هر بار مقدار کمی از آنها را انجام می‌دهد. (بخش "اقدامات XP" در صفحه قبل، نگرش فلسفی و اقدامات XP را نشان می‌دهد. این اقدامات به گونه‌ای طراحی شده‌اند که امکان استفاده همزمان از آنها وجود داشته باشد و تلاش برای استفاده یکی از آنها، خیلی زود منجر به استفاده از بقیه گردد.

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

مشتری داستانهای تکرار بعدی را نیز با انتخاب باارزش‌ترین داستان‌های باقی‌مانده از انتشار و اطلاع از هزینه هر یک از آنها و سرعت تیم مشخص می‌کند. برنامه‌نوسان داستان‌ها را به وظیفه‌های(task) کوچک‌تری تبدیل می‌کنند تا توسط هر یک از آنها قابل انجام باشد.

سپس هر برنامه‌نویس یک وظیفه را به مجموعه‌ای از موردهای آزمون(test cases) تبدیل می‌کند. موردهای آزمون نشان‌دهنده پایان درست هر وظیفه هستند. هر برنامه‌نویس با همراهی یکی دیگر از برنامه‌نویسان -همکار-، ابتدا موردهای آزمون را می‌نویسد(در این مرحله اجرای آنها مؤفقیت‌آمیز نیست چون کد برنامه نوشته نشده است) و سپس با طراحی و نوشتن کدهای برنامه باعث اجرای درست موردهای آزمون و پشت‌سر گذاشتن آنها می‌شود. طراحی با رعایت اصل "حفظ ساده‌ترین طراحی ممکن برای کل سیستم" انجام می‌شود.

شکل 2: XP در بازه‌های زمانی مختلف. در بازه‌ ماه و سال، داستانهای انتشار جاری و انتشارهای آینده وجود دارند. در بازه‌ هفته و ماه، با داستان‌های تکرار جاری و داستانهای باقی‌مانده از انتشار جاری سروکار دارید. در بازه‌ روز و هفته، با وظیفه‌هایی که روی آنها کار می‌کنید و بعد با وظیفه‌های باقی‌مانده از تکرار جاری رو به رو هستید. در بازه‌ دقیقه و روز، با موردآزمونهایی که روی آنها کار می‌کنید و بعد بقیه موارد آزمون قابل تصور سروکار دارید.

 داستان
XP  به دوره‌ قبل از اولین ورود سیستم به مرحله بهره‌برداری(Production) توجه ویژه‌ای دارد[دوره منجر به تولید نسخه یک نرم‌افزار]. این دوره می‌تواند منجر به ناهنجاری خطرناکی در پروژه شود و از این رو باید در سریع‌ترین زمان ممکن طی گردد. به هر حال پروژه باید از جایی شروع شود.

این تصمیم که  سیستم چه کاری می‌تواند انجام دهد و چه کاری بهتر است انجام دهد، اولین تصمیم پروژه است. این تصمیم معمولاً در حوزه تحلیل است(مستطیل آبی کم رنگ در بالای شکل 1.c). تا زمانی که ندانید چه چیزی باید پیاده‌سازی شود، نمی‌توانید برنامه‌نویسی را شروع کنید.

نتایج تحلیل در قالب داستانها در کنار هم قرار می‌گیرند. می‌توانید آنها را مجموعه‌ای از موردهای کاربرد(use case) فرض کنید که هر یک روی کارتی (index card) نوشته شده است. هر داستان باید کسب‌وکار محور (business-oriented)، آزمون‌پذیر و قابل برآورد باشد.

یک ماه زمان مناسبی برای شناسایی داستانهای یک پروژه ده نفر سال (ده نفر در یک سال) است. قبول داریم که این زمان برای شناسایی کامل همه موارد کافی نیست. اما توجه داشته باشید که تا پیاده‌سازی شروع نشود، نمی‌توان همه موارد را کامل و دقیق شناسایی کرد حتی اگر تا ابد هم وقت داشته باشیم.

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

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

مقدمه
مقاله Agile Software Development: The Business of Innovation نوشته Jim Highsmith و Alistair Cockburn دو تن از امضاءکنندگان بیانیه چابک(Agile Manifest) است. این مقاله در سپتامبر سال 2001 یعنی حدود هفت ماه پس از امضای بیانیه در مجله IEEE Computer چاپ شده است.

این مقاله شامل بخشهای زیر است:
+ مسأله
+ پاسخ متدهای چابک
++ اصول بنیادی
+ بیانیه نرم‌افزار چابک
+ قواعد زاینده
+ اقدامات چابک
++ برنامه‌ریزی ویژگی و اولویت‌بندی پویا
++ بازخورد و تغیییر
++ تأکید بر کارتیمی

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

رویکردهای چابک از جمله XP‏ ،Crystal،‏ Lean Development،‏ Scrum و‏ ASD از دریچه­ای به تغییر می­نگرند که نشانگر آشفتگی محیط کسب­وکار و تکنولوژی کنونی است. 

مسئله
به تازگی در تحقیقی که Michael Mah در QSM Associates بر روی بیش از 200 پروژه توسعه نرم افزار
انجام داده، گزارش داده است  محققان قادر به یافتن تقریباً نیمی از طرحهای^[1] اولیه پروژه­ها برای مقایسه با یکدیگر نشدند. چرا ؟ زیرا هدف اصلی، اجرای پروژه مطابق با طرح اولیه نبوده و  به جای آن، راضی نگه­داشتن مشتری -در هنگام تحویل پروژه و نه در آغاز آن– اولویت پیدا کرده است.

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

پذیرش اعتبار نظریه "ضرایب متغیر هزینه­ Barry Boehm"مبنی بر اینکه  هزینه تغییرات در طول چرخه حیات پروژه ثابت نبوده و افزایش می­یابد، بدین معناست که پرسش اصلی، چگونگی مدیریت تغییرات ناخواسته در پروژه است و نه چگونگی جلوگیری از بروز آنها.

روش­های رایج فرض می­کنند فقط با تلاش بیشتر می­توان مجموعه کاملی از نیازمندی­ها را در اسرع وقت شناسایی و پیش‌بینی کرد و از این رو هزینه‌ها را با جلوگیری از ایجاد تغییرات کاهش داد. امروزه نپذیرفتن و انجام ندادن سریع  تغییرات به معنی بی توجهی به شرایط و موفقیت کسب­وکار است.

روشهای رایج مدیریت فرایندها نیز با اندازه­گیری­های مستمر، شناسایی خطاها و بهبود فرایند می‌کوشند تا تغییرات را در جایی خارج از فرایندها مدیریت کنند. این روشها فرض می­کنند خطاها عامل تغییرات هستند. هر چند برخی خطاها ناشی از مشکلات فرایندها هستند اما واقعیت این است که عامل ایجاد تغییرات اساسی‌، تغییرات محیطی­اند. از آنجایی که قادر به حذف تغییرات محیطی نیستیم، کاهش هزینه انجام آنها، تنها استراتژی بادوام و درازمدت است. به عبارت دیگر، استراتژی جدید به جای حذف دوباره کاری(بازکاری)، سعی در کاهش هزینه آن دارد.

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

گزیده:
لازم نيست آدم از كوهي بالا رود تا بفهمد بلند است.  پائولو كوئيلو
مرجع: اس.جی.

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

استاد گرانمایه، انسان دوست‌داشتنی و آموزگار دانا، استاد روحانی رانکوهی در یکی از کلاسهای پایگاه داده روی تابلو نوشت: پایگاه داده. سپس ادامه داد، دانشجویان عزیز، این زبان «مادری» است. در گوشه‌ دیگری از تابلو نوشت: 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) است.

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

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

گزیده:

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

تازه‌کار: سلام
چابک: سلام. چهره‌ات نشان از سردرگمی دارد. می‌توانم کمک کنم؟

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

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

 تازه‌کار: نام چابک از کجا آمد؟
چابک: پس از مدتی چند تن از پیشروان این پارادایم، به دعوت باب مارتین (رابرت سی مارتین معروف به عمو باب) در جایی جمع شدند. هدف اصلی گردهمایی این بود که بین متدهای سبک شامل Adaptive Software Development, XP, Scrum, Crystal, Feature-Driven Development, Dynamic System Development Method (DSDM), and "pragmatic programming." مشابهتی وجود دارد یا خیر.

یکی از نتایج گردهمایی، نامگذاری این گونه از متدها بود. در آن گردهمایی مجموعه‌ای از اسامی پیشنهاد شد و پس از مراحلی، بین دو نام چابک (agile) و سازگار (adaptive) رای به چابک داده شد، هر چند عنوان دوم در بسیاری از مراجع و حتی توسط بسیاری از پیشروان این متدها هنوز به کار برده می‌شود. 

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

سطوح دوم و سوم به صورت بیانیه‌ای (Agile Manifest) صادر و توسط این افزاد امضاء شد. این افراد پس از آن، Agile Alliance را نیز پایه‌گذاری کردند.

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

هدف اصلی متدهای چابک تحویل سریع­تر نرم­افزار و کسب اطمینان از پوشش نیازهای در حال تغییر مشتری است. بطور کلی این متدها بر چهار موضوع انسانها و تعاملات بین آنها، پذیرش تغییرات نیازمندی­ها، تحویل زود به زود نرم­افزار قابل استفاده و همکاری نزدیک مشتری و توسعه­دهندگان تأکید دارند.

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

تازه‌کار: مگر شما نگفتید که چابک خیلی خوب است.
چابک: چرا!
تازه‌کار: خوب. پس باید شروع کنیم.
چابک: حتماً ابتدا شروع می‌کنی یک بک‌لاگ محصول می‌نویسی،..، بعد هم تکرارهای ماهانه (اسپرینت) خواهی داشت، جلسات ایستاده روزانه برگزار می‌کنی؟

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

بگذارید آماری را خدمت شما ارائه دهم. مؤسسه Standish Group در گزارش سال 2011 خود، اعلام کرده است که:
9 درصد پروژه‌های چابک شکست خورده‌اند.
49 درصد ....  دچار چالش بوده‌اند.
42 درصد .... با مؤفقیت پایان یافته‌اند.

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

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

 تازه‌کار: بسیار خوب.
چابک: بقیه‌اش باشد برای بعد. تعطیلات خوش بگذرد.
تازه‌کار: به شما هم همینطور.

مراجع:
سیلابس دوره متدهای چابک (Agile Methods)
Agile Software Development: The Cooperative Game, 2^nd, Alistair Cockburn
Standish Group, CHAOS Report, 2011

گزیده:

Agile methods derive much of their agility by relying on the tacit knowledge embodied in the team, rather than writing the knowleadge down in plans.
 Barry Boehm

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

تازه‌کار: شما را که می‌بینم یاد یوزپلنگ و ببر می‌افتم.
چابک: یعنی قیافه من شبیه یوزپلنگ است
تازه‌کار: نه! نه! آخر همه جا چابکی را با تصویر ببر یا یوزپلنگ نمایش می­دهند.
چابک: خوب! متوجه شدم. نه این تصور درست نیست.
تازه‌کار: یعنی شما یوزپلنگ نیستید؟
چابک: ها ها. التبه که نه. من چابک هستم، انسانی مثل خود شما. اجازه دهید برای رفع سوءتفاهم ابتدا تعریفی از چابکی ارائه دهم.
تعریف چابکی سازمانی یا چالاکی را می­توانید در اینجا ببینید.

چابکی «توانایی واکنش(پاسخ) سریع به تغییرات و ریسکها است»
حال که شما از یوزپلنگ صحبت کردید، اجازه دهید از دنیای حیوانات مثالی بیاورم. با تعریف گفته شده، فیل، خرگوش، زرافه و حتی یوزپلنگ، همگی چابک هستند. چرا که در طول تاریخ، با پذیرش تغییرات و تطابق­پذیری با محیط به حیات خود ادامه داده­اند، در حالی که دایناسورها نتوانسته­اند به حیاتشان ادامه دهند. جایی خوانده­ام که ظاهر زرافه کاملاً با شرایط آب و هوایی محل سکونتش تطابق دارد. اگر دقت کرده باشید (همان طور که در تعریف مشخص است)، سرعت، ویژگی چابکی نیست، بلکه سرعتِ تطببق­پذیری با تغییرات محیط و ریسکهایش، ویژگی بارز چابکی است.
تازه‌کار: متوجه شدم. چه جالب.

چابک: فیلها که نماد کندی هستند، در طول تاریخ، زنده مانده­اند و چه بسیار جانوران تند و تیزی که امروز اثری ازآنها باقی نیست. پس سرعت، ویژگی بقا نیست. سرعت پذیرش تغییرات محیطی، راز بقاست.
تازه‌کار: با شما مؤافق نیستم. نماد کندی، فیلها نیستند.
چابک: پس چیست؟
تازه‌کار: رحیم، برادرم!
چابک: بله!
تازه‌کار: آخر وقتی که می‌خواهیم از خانه بیرون برویم، دردسر داریم. عروس خانم در روز عروسی زودتر آماده می‌شود تا این آقا رحیم ما! همه خانواده نگران روز دامادی‌اش هستند، می‌خواهند سه روز زودتر از روز عروسی، او را بفرستند تا آماده مراسم شود!

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

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

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

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

پیش‌گفتار یک:
داستان‌گویی و نشستهای همراه با پرسش و پاسخ یکی از روشهای زیبا در انتقال مطالب به خواننده است. در اولی، نویسنده یا گوینده، داستانی را تعریف می‌کند و در دومی، نشستی بین دو یا چند نفر برگزار می‌شود. یکی از بهترین نمونه‌های این تکنیک را می‌توان در کتاب Head First Design Pattern دید.

پیش گفتار دو:
پرسشهایی که از دیگران می‌پرسم، پرسشهایی که پاسخگو هستم و بسیاری از آموخته‌ها، وقتی به شیوه رایج نوشته می‌شوند، اثربخشی خود را از دست می‌دهند. دست کم، آن چه را که انتظار دارم، بیان نمی‌کنند. تصمیم گرفتم تجربه‌ای در این گونه نوشتن، داشته باشم. امیدوارم که مؤثر باشد.

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

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

گفتار: مخاطرات چابک‌کاری
تازه‌کار: اگر سه جنبه فرایند، تکنولوژی و افراد را در ایجاد نرم‌افزار در نظر بگیریم، کدام جنبه برای شما، اهمیت بیشتری دارد؟
چابک‌: پاسخ ساده است: افراد

تازه‌کار: یعنی دو جنبه دیگر برایتان اهمیتی ندارند؟
چابک: نه این طور نیست. با تمرکز و تأکید بر افراد، اجازه می‌دهم تا آنان در مورد تکنولوژی و فرایند، تصمیم‌گیری کنند.

تازه‌کار: ویژگی‌های «افراد»ی که نام بردید، چیست؟
چابک: منظورتان را متوجه نشدم. افراد، کسانی هستند که در ایجاد نرم‌افزار نقش دارند.

تازه‌کار: اجازه دهید مثالی عرض کنم. آیا کسانی با مشخصات زیر مد نظر شما هستند؟
-         افراد برنامه‌نویسی مثلاً برنامه‌نویسی شیءگرا را به درستی نمی‌دانند.
-         "     مبانی و اصول طراحی را به درستی نمی‌دانند.
-         "  با ظرافتهای طراحی پایگاه داده آشنا نیستند.
-         "     مفاهیم و مبانی معماری را به درستی نمی‌دانند.
-         "   روش مقابله با ریسکها و ایجاد ارزش افزوده در کار را نمی‌دانند.
-         "   کار تیمی و روش مشارکت را به درستی نمی‌دانند.
-         " مهارتهای ارتباطی را به درستی نمی‌دانند.
-         ...
چابک: متوجه منظورتان شدم. البته که پاسخ من «خیر» است. قبل از این که پاسخم را کامل کنم، می‌توانم بپرسم که چرا این پرسش را پرسیدید؟

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

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

تازه‌کار: خوب اگر قرار باشد که موضوعات گفته شده را به درستی بدانم، با هر شیوه‌ای که کار کنم، مؤفق خواهم بود.
چابک: هر چند با گفته شما تا حد زیادی مؤافق هستم، ولی اجازه دهید، مثالی بیان کنم. فرض کنید که می‌خواهیم در مورد برنامه‌ریزی کارهای پروژه با هم طرحی را تهیه کنیم. این که وظیفه (Task) را مبنای برنامه‌ریزی قرار دهیم یا ویژگی‌های(Feature) سیستم را، دو رویکرد متفاوت است. این که کارکردهای سیستم را در ابتدای پروژه شناسایی کنیم با این که اجازه دهیم کم‌کم و به مرور آنها تکمیل گردند، دو رویکرد متفاوت است. آنجایی که  من می‌توانم به شما کمک کنم، در جااندازی این گونه رویکردهاست.

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

تازه‌کار: حتماً. اگر اجازه بفرمایید این گفت‌وگو را در زمانی دیگر ادامه دهیم.
چابک: مؤافقم.
تازه‌کار: سپاسگزارم.

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

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

موضوع: پارادایم و تغییر پارادایم

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

این واژه، نخست در سده پانزدهم و به معنی «الگو و مدل» مورد استفاده قرار گرفت. از سال ۱۹۶۰ کلمه پارادایم به الگوی تفکر در هر رشته علمی یا ... گفته می‌شود. لغت‌نامه مریام-وبستر این واژه را چنین تعریف می‌کند: «یک چارچوب فلسفی و نظری از یک رشته یا مکتب علمی در کنار نظریه‌ها، قوانین، کلیات و تجربیات به دست آمده که قاعده‌مند شده‌اند».

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

پاردايم‌ها حاكمان واقعي جهان هستند و راهنمايي براي حل مسائل انسان به شمار مي‌روند. هر پاراديم محدوده‌اي از عالم هستي است و قواعد آن را برروي ما مي‌گشايد و پيش فرض‌ها و باورها و برداشت‌هاي ما را نسبت به موضوعات تعيين مي‌كند. پاردايم به منزلة نقشه است كه چگونگي راه رانشان مي‌دهد. ولي هيچ نقشه‌اي نمي‎تواند واقعيت راه را به تمامي در ذهن ما تصوير كند.

واژه تغییرپارادایم (تغییر پارادیم یا Paradigm Shift) اولین بار در سال ۱۹۶۲ توسط توماس کوهن در کتاب ساختار انقلاب‌های علمی، برای توصیف تغییر در مفروضات اساسی در دوره حکمرانی یک نظریه از علم به کار گرفته شد و پس از آن در بسیاری از حوزه‌های تجربیات انسانی مورد استفاده قرار گرفت.
تغییر پارادایم، تغییر آرام در روش‌شناسی یا تجربه ‌است و غالباً به تغییر اساسی‌ای در تفکر و برنامه اطلاق می‌گردد که سرانجام روش اجرای پروژه‌ها را تغییر می‌دهد.

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

مرجع

خصوصيت مهم ديگر پارادايم‌ها اين است كه با ايجاد يك چارچوب نگرشي بر پيش فرض‌هاي انسان به شدت تأثير مي‌گذارند تا حدي كه پايبندان به پاراديم را از درك حقايق خارج از پاراديم محروم مي‌سازند. اين ويژگي موجب مي‌شود نوآوري و خلاقيت در فضاي پارادايم تنها به مرزهاي آن محدود شود.

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

کوهن بر این باور بود که تکامل تدریجی علم به سمت حقیقت نیست، بلکه دستخوش انقلاب‌های دوره‌ای است که او آن را «تغییر پارادایم» می‌نامد.

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

 گزیده:
سریعترین راه برای نیل به موفقیت دوبرابر کردن تعداد شکستها است.
توماس واتسون

سمینار «نیازمندی‌های چابک(Agile Requirements)» برگزار شد. از همه شرکت‌کنندگان گرامی که قبول زحمت کردند، سپاسگزارم.

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

در سمنیار بخشی را اضافه کرده بودم با نام "آیا برای چابکی آماده‌اید؟(Are You Ready for Agile)" که در آگهی سمینار نبود. این بخش را بیش از همه دوست می‌داشتم.  

فایل ارائه سمینار را می‌توانید از اینجا دریافت کنید.

گزیده:
همیشه در زندگیت جوری زندگی کن که "ای کاش" تکیه کلام پیریت نشود.