به نام خدا
XP یا Extreme Programming در واقع یک فرآیند توسعه نرم افزار عمیق و منظم می باشد. این روش از سال 1990 توسط شخصی به نام Kent Beck به همراه Ward Cunningham این فرآیند را برای توسعه آسان نرم افزارها ایجاد و در سالهای بعد آن را تکمیل کردند به نحوی که از سال 1996 به عنوان یک روش مناسب کاربردهای خود را نشان داد و هم اکنون در شرکتهای مختلفی با سایز های متفاوت مورد استفاده می باشد. یکی از دلایل موفقیت این روش تاکید آن بر رضایت مشتری است. این متدلوژی برای ارائه چیزی که واقعا مشتری نیاز دارد طراحی شده است. همچنین این روش کمک می کند که نیازهای مشتری را حتی در پایانی ترین مراحل تولید در سیستم اعمال کنند. از دیگر تاکید های روش توجه به کار گروهی است و این کار را با ساده ترین و مؤثرترین راه انجام می دهد.. مدیران، مشتریان و توسعه دهندگان همه اعضای تیمی هستند که مختص تحویل یک نرم افزار خوب (با کیفیت) ایجاد شده است.
XP یک پروژه نرم افزاری را در چهار وجه ، ارتباطات (Communication) ، سادگی (Simplicity) ، بازخورد ها (Feedback ) و شجاعت (Courage ) بهبود می بخشد: 1-برنامه نویس XP ابتدا با مشتری ارتباط بر قرار می کند، سپس برنامه سازی را دنبال می کند. 2- آنها طراحی خود را ساده و تمیز نگه می دارند. 3- با آزمایش نرم افزارهای خود ار روز اول بازخورد می گیرند. 4- سیستم را در اولین فرصت به مشتری تحویل می دهند و تغییرات را به محض پیشنهاد دادن انجام می دهند. بر پایه XP، برنامه نویسان قادر خواهند بود که شجاعانه به تغییرات نیازها و فنآوری پاسخ دهند.
XP شامل اجزا زیاد کوچکی است که در نگاه اول هر کدام معنی خاصی نمی دهد اما وقتی بایکدیگر ترکیب شدند یک تصویر کامل می سازند. این یک فاصله اساسی با توسعه سنتی نرم افزارها ایجاد می کند. در یک کلام XP متفاوت است.
مطلب بالا خلاصه است از ادعاهایی که طراحان XP در مورد روش خودشان مطرح کرده اند. در سلسله مطالبی، به مرور این روش خواهیم پرداخت.
اعضای تیم در پروژه
در روش اکس‌پی مشتری نرم‌افزار باید جزئی از تیم اجرایی پروژه باشد و برنامه‌نویس و مشتری باید با هم کار کنند و از مشکلات و نیازهای هم مطلع باشند. در اکس‌پی مشتری به کسی یا گروهی گفته می‌شود که نیازهای برنامه و اولویت‌های آن نیازها را خوب می‌داند. در این روش مشتری و برنامه‌نویسان باید در یک اتاق کار کنند (البته تبصره‌ای نیز در این قسمت وجود دارد که می‌گوید مشتری می‌تواند تا حداکثر پنجاه متر از برنامه‌نویسان دور باشد).
داستان‌های کاربران یا User Stories
برای این‌که بتوانیم برای پروژه‌ای برنامه‌ریزی کنیم، باید از نیازهای کاربران مطلع باشیم. البته نیازی نیست که همه چیز را از همان اول بدانیم و از جزئیات نیازهای کاربران اطلاعاتی کسب کنیم؛ زیرا آن جزئیات به احتمال زیاد در طول پروژه تغییر پیدا می‌کنند. در اکس‌پی باید در مورد هر نیاز کاربر یا Requirement مقداری با مشتری صحبت کنیم و از مشتری بخواهیم چند کلمه‌ای در مورد هر یک از نیازها روی فیش یا کاغذهای یادداشت چسب‌دار (Post-it) بنویسد. همزمان برنامه‌نویس نیز می‌تواند برداشت خود را از آن موضوع روی کاغذی مشابه بنویسد و هر دو برگه را روی دیوار اتاق بچسبانند. این برگه‌ها می‌توانند باعث یادآوری اعضای تیم از نیازهای اولیه و همچنین سهولت در تخمین زمان و هزینه پروژه شوند.
دوره‌های زمانی کوتاه
پروژه اکس‌پی هر دوهفته یک بار یک قسمت از نرم‌افزار که کارایی بالایی دارد و قسمتی از نیازهای اولیه مشتری بوده است را تحویل می‌دهد و از مشتری در مورد آن قسمت نظرخواهی می‌شود و اگر نیاز بود، نظر مشتری سریعاً اعمال می‌گردد. به این دوره دو هفته‌ای Iteration نیز می‌گویند. هر Iteration قسمتی از نرم‌افزار را با توجه به User Storiesها تولید می‌کند که چند نیاز کاربر را برآورده می‌سازد. وقتی یک Iteration شروع شد، دیگر مشتری حق عوض کردن نیازهایی که بر سر آنها توافق کرده است را ندارد.
تست های قبول شده
جزئیات نیازهای کاربران که در User Stories وجود دارد، در قالب Acceptance Tests) AT) که مشتری تعیین می‌کند برداشت می‌شود. این تست همزمان با Iteration می‌تواند انجام گردد و در قالب زبان‌های اسکریپتی نوشته می‌شود تا بتوان آن را چندین بار تکرار کرد. هدف اصلی ATها تست کردن برنامه و حصول اطمینان از این است که آن قسمت از برنامه نوشته می‌شود که صددرصد نیاز مشتری را برآورده می‌سازد.
این تست‌ها هر وقت که قسمت جدیدی به برنامه اضافه می‌شود و برنامه کامپایل می‌گردد، دوباره اجرا می‌شوند و اگر اشکالی داشته باشند، پیغام خطا می‌دهند. در نتیجه وقتی سیستم به اتمام رسید، می‌توان مطمئن بود که سیستم بدون خطا است.
به علاوه، در اکس‌پی تمامی کدها به روش Test-Driven Development تولید می‌شوند. یعنی قبل از نوشتن هر قطعه کد، باید تست آن تولید شود و کاری کرد که کد در پاس کردن Unit Test ناتوان باشد. بدین‌معنی که اول یک قطعه کد مثلاً برای افزودن دانشجوی جدید به فهرست دانشجویان می‌نویسیم، ولی چون در آن کد قطعه‌ای از کد کلاسی که insert را انجام می‌دهد وجود ندارد، برنامه اشکال می‌گیرد. حال کار گروه اکس‌پی این است که برنامه را طوری درست کنند که این تست پاس شود و به قدری روی برنامه کار کنند تا برنامه دلخواه به دست آید.
برنامه نویسی دوتایی
معمولاً در اکس‌پی برنامه‌نویسان در گروه‌های دوتایی قرار می‌گیرند و وظیفه تکمیل قسمتی از برنامه را به عهده می‌گیرند. هر دو برنامه‌نویس در مورد هر کدام از نیازهای کاربران با هم بحث می‌کنند و قدم به قدم کلاس‌های برنامه را آماده می‌کنند. بدین ترتیب که در ابتدا کلاسی را به صورت خیلی ابتدایی و بدون هیچ طراحی اولیه به وجود میآورند و این کلاس را امتحان می کنند و در صورتی که این کلاس فاقد هر گونه اشکال باشد، کد اصلی برنامه را بر اساس این امتحان کلاس می‌نویسند. وقتی یکی از برنامه‌نویسان مشغول نوشتن قسمتی از برنامه است، برنامه‌نویس دیگر وظیفه کنترل صحت این کدها را عهده‌دار است و در صورت مشاهده هر گونه اشکال، نویسنده کد را مطلع می کند.
تیم همه کاره
در اکس‌پی همه اعضای تیم همه کار می‌کنند. همه روی GUI، پایگاه اطلاعات و ... کار می کنند. این بدین منظور نیست که اعضای تیم نمی‌توانند در کار مشخصی حرفه‌ای باشند، بلکه همکاری در تمامی بخش‌های پروژه باعث خواهد شد که تجربه جدیدی کسب کنند. این تیم حق دارد کدهایی که دیگران نوشته‌اند را بارها چک کند، اشکالات آن را مشخص نماید و اگر اصلاحی دارد، آن را متذکر شود.
محیط کاری باز
تیم باید در مکانی باز کار کند. در اتاق پروژه باید میزهایی فراهم شوند که روی آن چند کامپیوتر قرار دارد. در جلوی هر کامپیوتر هم باید دو صندلی برای اعضای Pair تعبیه شود. دیوارهای اتاق باید از نقشه‌ها و طرح‌های نرم‌افزاری به همراه UML مملو باشد. صدای اتاقی که در آن کار انجام می‌شود، معمولاً پر از زمزمه‌های اعضای تیم است. شاید بگویید که در محیطی پر زمزمه که نمی‌شود کار کرد. در جواب این سؤال باید گفت طبق تحقیقاتی که در دانشگاه میشیگان انجام شده است، راندمان کار در محیط‌های کاری‌ای که در آن زمزمه باشد و سکوت محض نباشد، به دو برابر حالت عادی می‌رسد.
طراحی ساده نرم‌افزار
در اکس‌پی تیم سعی می کند طراحی نرم‌افزار را تا حد ممکن ساده انجام دهد. اعضای تیم تمام انرژی خود را فقط روی نیازهای فعلی کاربران می‌گذارند و نگران نیازهای جدیدی که ممکن است در آینده مطرح شوند، نیستند. در ابتدای کار تمرکز برنامه‌نویسان تیم به انتخاب پایگاه اطلاعاتی، انتخاب معماری نرم‌افزار و ... نیست و تمام سعی تیم این است که قسمتی از نرم‌افزار را به ساده ترین راه ممکن تحویل مشتری دهد و وقتی واقعاً به تغییرات نیاز پیدا شد، می‌توانند تغییرات لازم را اعمال نمایند.
در اکس‌پی اعضای گروه می‌توانند روند تکمیلی تولید نرم‌افزار را مشاهده کنند و در جریان کار قرار گیرند. اکس‌پی روش مناسبی برای پروژه‌های کوچک است که اعضای تیم از دو تا دوازده برنامه‌نویس تشکیل شده است؛ هرچند اصولاً اکس‌پی هیچ رویه خاص و مراحل پیوسته‌ای را مشخص نکرده است. می‌توان گفت که اکس‌پی چهار مرحله اصلی دارد:
●مرحله زمانبندی پروژه
●طراحی ابتدایی
●نوشتن کدهای برنامه
●امتحان کدهای نوشته شده
طبق تحقیقات انجام شده مشخص شده است که اکس‌پی تنها در پروژه‌های کوچک نرم‌افزاری می‌تواند مفید باشد و در پروژه‌های بزرگ، اصلاً موفق نخواهد بود. شاید به این دلیل که در این روش مستندات چندانی برای نرم‌افزار وجود ندارد و چند نفر بیشتر نمی‌توانند در مورد قسمتی از نرم‌افزار اطلاعاتی داشته باشند. همچنین نرم‌افزار تولید شده با این روش هیچ‌گونه طراحی سازمان یافته‌ای ندارد و این امر می‌تواند برای مراحل پس از نصب، یعنی تعمیرات و نگهداری سیستم، باعث بروز مشکلاتی گردد.
از جمله مزایای اکس‌پی این است که از آن جایی که یک برنامه‌نویس به صورت مستقیم کدهای برنامه را چک می‌کند، کیفیت نرم‌افزارهای تولیدی بالاتر می‌رود. همچنین از آن جایی که دو برنامه‌نویس با هم کار می‌کنند، آموزش کمتری نیاز است و در نتیجه هزینه تولید نرم‌افزار پایین میآید، اما این روش مشکلات خاصی نیز دارد. مثلاً تصور کنید اگر در یک گروه یک برنامه‌نویس تمایلی برای کار با دیگر برنامه‌نویسان نداشته باشد، چه اتفاقی خواهد افتاد؟!
متخصصان نرم‌افزار پس از تحقیقات زیاد روی این روش به این نتیجه رسیده‌اند که وقتی برنامه‌نویسی در کدهای برنامه به دنبال اشکال می‌گردد، حداکثر می‌تواند پانزده درصد از اشکالات برنامه را پیدا کند، ولی در روش‌هایی مانند اکس‌پی که دو برنامه‌نویس با هم کار می‌کنند و یکی از این برنامه‌نویسان کدها را چک می‌کند، تا چهل درصد از اشکالات ساختاری برنامه مشخص می‌شود.
پاسخ با نقل قول
