در آغوش گرفتن تغییرات با XP – بخش اول

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

۱۳- فقط قواعد(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