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

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

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

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

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

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

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

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

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

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

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

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

رویداد اول: دوره‌ای با شرکت کارشناسان زبده و باتجربه‌ی تعریف محصولات نرم‌افزاری
در نقش مدیر کتابخانه یکی از دانشکده‌های دانشگاه از آنها خواستم تا ویژگی‌های(Feature) سیستم کتابخانه را به همراه مدت و هزینه انجام پروژه اعلام کنند. در قالب گروه‌هایی شروع به کار می‌کنند. در پایان از دو گروه خواهش می‌کنم که پاسخ‌هایشان را روی تابلو بنویسند.
ثبت امانت، برگشت کتاب، تعریف عضو، ….
پس از آن از همه می‌خواهم که توجه کنند و این پرسش را مطرح می‌کنم: “شما به دنبال حل چه مسأله‌ای و مشکلی از مشتری بوده‌اید؟”.
به ناگاه همه ساکت می‌شوند، چند لحظه‌ای به سکوت می‌گذرد و بعد همه با هم شروع به خندیدن می‌کنند. دلیل خندیدن آنها این است که پی‌می‌برند اشتباهی را مرتکب شده‌اند که از افراد تازه‌کار انتظار می‌رود. آنها راه حل را بدون توجه به نیاز مشتری ارائه کرده‌اند.

رویداد دوم: دوره‌ای مرتبط با متدهای چابک (agile methods)
به عنوان مشتری از شرکت‌کنندگان خواسته‌ام تا بک‌لاگ محصول را در قالب تیم‌هایی کامل کنند. در پایان از آنها می‌پرسم: «کدامیک از ارزشها و اصول چابکی را به کار بردید؟». به موارد مهمی اشاره می‌کنند از جمله مشارکت: همه تیم در کار مشارکت داشتند. بعد از آنها می‌پرسم: می‌توانم بپرسم که در زمان «مشارکت»، مشتری کجا بود – اشاره به مشارکت مشتری در تیمهای چابک-؟». دقایقی به بحث و گفت‌وگو می‌گذرد. یکی از شرکت‌کنندگان به شوخی می‌گوید: مشتری در حال قدم زدن در کلاس بود-اشاره به من که موقع انجام تمرین در کلاس قدم می‌زدم. یکی دیگر می‌گوید: نمی‌خواستیم مزاحم وقت مشتری شویم.
همه می‌خندیم. همه پی‌می‌بریم که یک نکته اساسی را که می‌دانستیم، فراموش کرده‌ایم.

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

خوشحال خواهم شد که خواننده نظرات و راهنمایی‌های شما باشم.

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

1-اصول و مبانی هیچ گاه کهنه نمی‌شوند.
پروژه‌های بزرگ و طولانی می‌توانند ترسناک و حتی در شرایط بد شبیه به نزدیک شدن لحظه مرگ باشند- با برداشتن هر قدم، یک قدم به مرگ نزدیکتر می‌شوند. به گفته بوچ، پروژه‌های با بهره‌وری بالا هیچگاه چهار موضوع اصلی زیر را فراموش نمی‌کنند:
1- ایجاد انتزاعهای (abstraction) دقیق و انعطاف‌پذیر
2- جداسازی موضوعات مهم (separation of concerns)
3- تخصیص توزیع‌شده و متعادل مسئولیت بین اجزاء
4- تأکید بر سادگی

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

2-نیاز به ریتم (دوره منظم) انتشار دارید
هر پروژه نیاز به ضرب‌آهنگی شبیه به ضربان قلب دارد. وی می‌گوید:«ایجاد ریتم موجب افزایش ثبات و قابل پیش‌بینی بودن پروژه می‌شود». …

3-تمرکز بر معماری قابل اجرایی که به مرور کامل می‌شود
… «واقعیت، کد برنامه است» اما «کد برنامه همه واقعیت نیست» [خیلی‌ها عقیده دارند که کدبرنامه تنها واقعیت پروژه است و می‌تواند جایگزین خیلی چیزها از جمله معماری، مستندات و … شود]

4- ایجاد ساختارهای اجتماعی که با حفظ قابلیت پیش‌بینی، موجب افزایش نوآوری شوند
کارتیمی عنصر اصلی هر پروژه بزرگ نرم‌افزاری است…. کسب‌وکار نیاز به پیش‌بینی دارد (نرم‌افزار کی آماده تحویل می‌شود؟) و در کنار آن نیاز به نوآوری. ایجاد ساختارهای اجتماعی که هر دو هدف را محقق کند، کار ساده‌ای نیست، اما پروژه‌های مؤفق توانسته‌اند نقطه تعادل بین آن دو – پیش‌بینی و نوآوری- را پیدا کنند.
یکی از نقاط مورد بحث و مجادله در ساختارهای اجتماعی میزان مشارکت مدیران در فرایند ایجاد و توسعه نرم‌افزار است. گریدی بوچ اعتقاد دارد که با وجودی‌ که خطی بین مدیران و توسعه‌دهندگان وجود دارد، اما به عنوان مثال معمار بهتر است عضوی از تیم پیاده‌سازی تیم هم باشد. هر چند با مشارکت زیاد مدیران، امکان ایجاد اشکالاتی در روابط تیم وجود دارد، اما به یاد داشته باشید که بین «خط» و «دیوار» تفاوت وجود دارد-خط یا دیوار بین مدیران و اعضای تیم-….

5- لذت ببرید
این توصیه، یک توصیه دوستانه ساده نیست. بوچ اعتقاد دارد که پروژه‌های مؤفق، نتیجه کارِ تیمی است که از کارش لذت می‌برد. «اکثر انسانها می‌خواهند کارهای زیبا و برازنده انجام دهند. اگر به این خواسته درونی آنها بی‌توجه باشید، در حقیقت شوق رشد و پیشرفت را از آنها گرفته‌اید»
مرجع:www.cio.com

گزیده:

A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system.
John Gall

بخش اول ترجمه مقاله 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)، آزمون‌پذیر و قابل برآورد باشد.

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

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

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

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

امیدوارم روزی این گونه نگاه به مسائل در کشورمان بدیهی گردد.

«مقاله: درباره نوبل اقتصاد 2012؛ تئوری بازی‌ها، برای بازی نیست!
آکادمی سلطنتی سوئد، جایزه نوبل اقتصاد خود را در سال 2012 به آلوین‌راث و لوید شپلی اهدا کرد.
دو آمریکایی که در زمینه تئوری بازی‌ها کار کرده اند. مسائل طراحی بازار (Market Design) و تخصیص‌های پایدار (Stable allocations) یکی از جالب‌ترین موضوعات در تئوری بازی‌ها است.
اغلب این سرفصل با «مشکل ازدواج پایدار» مطرح می‌شود. پرسش این است چه مکانیسمی باید طراحی کرد تا n تعداد زن با n تعداد مرد ازدواج کنند، به شکلی که برای هر دو نفر با جنسیت مخالف، گزینه بهتری نسبت به آن کسی که دارند، نباشد. اگر کسی نباشد این ازدواج‌ها پایدار خواهند بود.

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

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

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

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

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

مرجع: دنیای اقتصاد

گزیده:

There can be no liberty unless there is economic liberty. Margaret Thatcher

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

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

مرجع: دنیای اقتصاد

گزیده:
«نتیجه ارادهٔ ضعیف حرف است و نتیجهٔ اراده قوی، عمل.» گوستاو لوبن

متن زیر بخش اول ترجمه مقاله Embracing Change with Extreme Programming نوشته Kent Beck است در IEEE Software در سال 1999 منتشر شده است.
این مقاله توسط دوست گرامی جناب آقای مهندس مهدی نگاهی ترجمه شده است.

————————————————————————————————-

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

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

ولی همه چیز خوب نبود. کاربران یک‌جا و دقیق نمی‌گفتند که چه می‌خواهند. آنها نیازهایشان را نمی‌دانستند. حتی گفته‌های خود را نقض می‌کردند. فکرشان نیز تغییر می‌کرد. ولی مشکل فقط کاربران و مشتریان نبودند. ما برنامه‌نویسان نیز فکر می‌کردیم با انجام ¾ کار طبق برنامه، پیشرفت بزرگی در پروژه کرده‌ایم در حالی که عملاً فقط ₃/¹ کار انجام شده بود.

چرخه‌های بلندمدت توسعه خوب نبودند چرا که نتوانستند خود را با تغییرات سازگار کنند. این موضوع شاید بدین معناست که آن چه نیاز داشتیم ایجاد چرخه‌های کوتاه‌تر بود. بنابراین همان طور که شکل 2 نیز نشان می‌دهد مدل آبشاری عامل ایجاد تکرارها^۱ بوده است.

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

جامعه دانشگاهی مهندسین نرم‌افزار که هزینه زیاد تغییر نرم‌افزار را به عنوان یک چالش معرفی کرده است، تکنولوژی‌هایی نظیر پایگاه داده‌ رابطه‌ای، برنامه‌نویسی ماژولار^۲ و مخفی‌سازی اطلاعات را ایجاد کرده‌ است. چه می‌شد اگر این تلاش‌های دشوار نتیجه می‌داد؟ چه می‌شد که ما در کاهش هزینه‌ تغییرات مداوم، خوب عمل می‌کردیم؟ چه می‌شد که مجبور نبودیم برای تسویه‌حساب با ساطور به جان مدل آبشاری بیفتیم؟ چه می‌شد اگر می‌توانستیم مدل آبشاری را در مخلوط‌کن بریزیم [و با هر چیز دیگری مخلوط کنیم]؟

تصویر 1: تکامل مدل آبشاری (a) و چرخه طولانی آن (تحلیل، طراحی، پیاده‌سازی و آزمایش) به مدل کوتاه‌تر با چرخه‌های تکرارشونده به عنوان مثال مدل حلزونی^۳(b) و از آنجا به XP (c) با ترکیب فعالیت‌ها و انجام مقدار کمی از آنها در هر بار ولی مدوام در طول فرایند توسعه نرم افزار

اقدامات^۴ XP
در زیر توضیح مختصری در مورد اقدامات مهم XP آورده شده است.
1- بازی برنامه‌ریزی(Planning Game)
مشتریان محدوده و زمان‌بندی انتشار^۵ را بر اساس برآورد برنامه‌نویسان تعیین می‌کنند و برنامه‌نویسان فقط کارکردهای درخواست‌شده در استوری^۶‌ها را در تکرار جاری پیاده‌سازی می‌کنند.

2- انتشارهای کوچک(Small Releases)
سیستم طی چند ماه –کوتاه‌ترین زمان ممکن- و قبل از حل کل مسأله برای استفاده آماده و راه‌اندازی می‌شود. انتشارهای جدید به کرات در بازه‌های روزانه تا ماهانه ساخته و منتشر می‌شوند.

3- استعاره (Metaphor)
چارچوب سیستم با استفاده از استعاره یا مجموعه‌ای از استعاره‌ها که بین مشتری و برنامه‌نویسان به اشتراک گذاشته شده، تعریف می‌شود.

4- طراحی ساده(Simple Design)
در هر لحظه، طراحی همه آزمونها را پشت سر می‌گذارد، هر آن چه که برنامه‌نویسان نیاز دارند، در اختیارشان قرار می‌دهد و کد تکراری در آن وجود ندارد و حاوی کمترین تعداد کلاس و متد است. خلاصه این قاعده این است: “هر چیزی را یک بار و فقط یک بار بیان کنید.”

5- آزمایش‌ها(Tests)
برنامه‌نویسان لحظه به لحظه آزمونهای واحد^۷ می‌نویسند که باید تجمیع و به درستی اجرا شوند. در هر تکرار، مشتریان آزمونهای کارکردی^۸ را برای استوری‌ها می‌نویسند که اجرای آنها نیز ضروری است. اجرای آزمونها در پایان تکرار منجر به شناسایی ایرادهای محصول می‌شود. در چنین شرایطی نیاز به تصمیم‌گیری سازمانی است تا از بین تحویل محصول با ایرادهای شناسایی‌شده یا قبول دیرکرد انتشار محصول پس از رفع ایرادها، یکی انتخاب شود.

6- بازسازی(Refactoring)
طراحی سیستم با تغییر طراحی موجود که همه آزمونها را پشت‌سر گذاشته، تکامل می‌یابد.

7- برنامه‌نویسی دو نفره(Pair Programming)
همه کد برنامه به صورت دو نفره با یک نمایشگر، صفحه کلید و موشواره -یک دستگاه- نوشته می‌شود.

8- یکپارچه‌سازی مداوم(Continuous Integration)
کد جدید حداکثر بعد از چند ساعت با سیستم موجود یکپارچه می‌شود. پس از آن، سیستم دوباره ساخته^۹ و همه آزمونها اجرا می‌شود، در صورت نامؤفق بودن آزمایش، کد جدید رد می‌شود.

9- مالکیت جمعی(Collective Ownership)
در صورت امکان بهبود، هر برنامه‌نویس موظف است هر کدی را در هر جایی از سیستم و در هر زمانی اصلاح کرده و بهبود بخشد.

10- مشتری مقیم(On-Site Customer)
مشتری به صورت تمام وقت در کنار تیم تولید است.

11- کارهفتگی 40 ساعته(40-hour Weeks)
هیچ کس نمی‌تواند دو هفته متوالی اضافه‌کاری داشته باشد. حتی اضافه‌کاری غیرمتوالی بیش از حد، نشانه وجود مشکلی عمیق است که نیاز به شناسایی و رسیدگی دارد.

12- محیط کار باز(Open Workspace)
اعضای تیم در یک سالن بزرگ کار می‌کنند که دور تا دور آن دارای پارتیشن‌های کوچک است. برنامه‌نویسی دونفره بر روی کامیپوترهایی انجام می‌شود که در وسط سالن قرار دارند.

13- فقط قواعد(Just Rules)
به عنوان بخشی از تیم XP متعهد به اجرای قواعد هستید. اما به یاد داشته باشید که اینها فقط یک سری قاعده‌اند. اعضای تیم می‌توانند قواعد را در هر زمانی تغییر دهند به شرطی که بر سر روش ارزیابی تغییرات ناشی از آنها توافق داشته باشند.

[۱] Iterations
[۲] Modular Programming
[۳] Spiral Model
[۴] Practices
[۵] Release
[۶] Story
[۷] Unit test
[۸] Functional tests
[۹] Build

گزیده:

Testing is not the point. The point is about responsibility. Kent Beck