برنامه نویسی شدید (XP) یکی از متدولوژی های توسعه چابک است نرم افزار. نویسندگان روش شناسی کنت بک، وارد کانینگهام، مارتین فاولر و دیگران هستند.

بازی برنامه ریزی

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

طرح انتشار

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

برنامه ریزی تکرار

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

جلسه ایستاده

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

سادگی

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

سیستم استعاره

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

مشتری در محل کار

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

تست قبل از توسعه

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

برنامه نویسی جفتی

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

تغییر سمت ها

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

مالکیت کد جمعی

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

کنوانسیون کدگذاری

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

ادغام مکرر

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

چهل ساعت کار در هفته

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

نتیجه

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

کتابشناسی - فهرست کتب:

برنامه نویسی افراطی (XP) به عنوان یک روش تکاملی توسعه نرم افزار از پایین به بالا سرچشمه گرفته است. این رویکرد نمونه ای از روش موسوم به روش توسعه چابک است. گروه روش‌های «زنده» علاوه بر برنامه‌نویسی شدید، شامل روش‌های SCRUM، DSDM (روش توسعه سیستم‌های پویا)، توسعه ویژگی محور (توسعه مبتنی بر توابع سیستم) و غیره است.

اصول اولیه توسعه نرم افزار "زنده" در مانیفست توسعه "زنده" که در سال 2000 ظاهر شد ثابت شده است.

• · افراد درگیر در پروژه و ارتباطات آنها مهمتر از فرآیندها و ابزارها است.
• · یک برنامه کاری مهمتر از مستندات جامع است.
• · همکاری با مشتری مهمتر از بحث در مورد جزئیات قرارداد است.
• · تمرین تغییرات مهمتر از دنبال کردن برنامه هاست.

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

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

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

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

· زندگي كردن برنامه ریزی بازی)

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

عکس. 1

· زود زود تغییر دادن نسخه های (کوچک منتشر شده)

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

· استعاره از سیستم

استعاره، به شکلی نسبتاً ساده و قابل درک برای تیم، باید مکانیسم اصلی سیستم را توصیف کند. این مفهوم یادآور معماری است، اما باید بسیار ساده تر، تنها در یک یا دو عبارت، ماهیت اصلی مورد قبول را توصیف کرد. راه حل های فنی.

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

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

· ساده طرح راه حل ها (ساده طرح)

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

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

· توسعه بر روی اساس تست (آزمایش محور توسعه)

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

XP بر دو نوع تست تمرکز دارد:

ь تست واحدها (تست واحد)؛

ь آزمون پذیرش (تست پذیرش).

نرم افزار برنامه نویسی شدید

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

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

برای XP رویکردی به نام TDD (Test Driven Development) اولویت بیشتری دارد، ابتدا تستی نوشته می‌شود که قبول نمی‌شود، سپس کد نوشته می‌شود تا تست بگذرد و پس از آن کد دوباره ساخته می‌شود.

· مقدار ثابت بازسازی

بر کسی پوشیده نیست که هر ویژگی جدیدی که اضافه می شود و کد در حال رشد است، توسعه، یافتن اشکالات و ایجاد تغییرات بعدی را دشوارتر می کند. یکی از ترفندهای Extreme Programming جبران اضافه شدن قابلیت ها با بهبود کد است. این همان refactoring یا refactoring کد است.

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

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

· برنامه نويسي به صورت جفت (جفت برنامه نويسي)

توسعه دهندگان باتجربه متوجه شده اند که بررسی دوره ای کد شخص دیگری تأثیر مثبتی بر کیفیت آن دارد. برنامه نویسان افراطی این رویکرد را توسعه داده اند: در طول توسعه، کد به طور مداوم از طریق تکنیکی به نام برنامه نویسی زوجی بازبینی می شود.

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

· جمعی مالکیت کد (جمعی مالکیت)

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

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

· مقدار ثابت ادغام (پیوسته ادغام)

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

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

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

· 40 ساعت کار کردن یک هفته

اضافه کاری به عنوان نشانه ای از مشکلات بزرگ در پروژه دیده می شود. اضافه کاری برای 2 هفته متوالی مجاز نیست - این برنامه نویسان را خسته می کند و کار آنها را به میزان قابل توجهی کاهش می دهد.

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

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

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

· شمول مشتری که در فرمان (در محل مشتری)

مشکل اصلی توسعه نرم افزار عدم آگاهی برنامه نویسان در حوزه موضوعی توسعه یافته است. Extreme Programming نیز راهی برای خروج از این وضعیت پیدا کرد. نه، این دوره کارآموزی توسعه دهنده در شرکت مشتری نیست - پس او نمی خواهد برنامه ریزی کند. برعکس، مشارکت مشتری در فرآیند توسعه است.

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

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

· استفاده کد چگونه منابع مالی ارتباطات

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

· باز کن کار کردن فضا (باز فضای کار)

این تیم در یک اتاق، به اندازه کافی بزرگ برای تسهیل ارتباطات و امکان بحث های جمعی در هنگام برنامه ریزی و تصمیم گیری های فنی مهم قرار دارد.

· تغییر دادن قوانین بر لازم است (فقط قوانین)

هر یک از اعضای تیم باید قوانین ذکر شده را بپذیرند، اما در صورت نیاز، تیم می تواند در صورتی که همه اعضایش با این تغییر موافقت کنند، آنها را تغییر دهد.

همانطور که از تکنیک های استفاده شده مشخص است، XP برای استفاده در تیم های کوچک (بیش از 10 برنامه نویس) طراحی شده است که توسط نویسندگان این تکنیک نیز مورد تاکید قرار گرفته است. اندازه تیم بزرگتر، سهولت ارتباط لازم برای موفقیت را از بین می برد و بسیاری از تکنیک های ذکر شده را غیرممکن می کند.

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

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

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

بنابراین، یک چرخه توسعه طولانی بد است زیرا قادر به انطباق با تغییرات نیست. سپس، شاید لازم باشد چرخه را کوتاه کنیم، و همه مشکلات حل شود؟ روی انجیر 1b تبدیل مدل آبشار به یک مدل تکراری را نشان می دهد.

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

جامعه دانشگاهی توسعه دهندگان نرم افزار مشکل هزینه بالای تغییر را بر عهده گرفتند و فناوری های جدیدی ایجاد کردند - پایگاه های داده رابطه ای، برنامه نویسی مدولار، پنهان کردن اطلاعات. اما اگر همه این آثار قبلاً پتانسیل خود را به پایان رسانده باشند چه؟ و ما می توانیم پیدا کنیم مسیر جدیدهزینه ایجاد تغییرات را با تکه تکه نکردن "آبشار"، بلکه به سادگی مخلوط کردن تمام اجزای آن کاهش دهید؟ نتیجه در شکل 1c نشان داده شده است. ما آن را "برنامه نویسی شدید" (XP) نامیدیم.

آناتومی XP

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

چرخه توسعه XP

روی انجیر 2 فرآیند XP مربوط به محورهای زمانی مختلف است که در آن سال ها، ماه ها، هفته ها و روزها به عنوان واحد اندازه گیری استفاده می شود. مشتری نسخه بعدی (انتشار) سیستم را تعیین می کند و با ارزش ترین ویژگی ها (در XP آنها را داستان - داستان می نامند) از همه موارد ممکن انتخاب می کند. ارزش توابع با هزینه مواد و زمان برای اجرای آنها توسط تیم توسعه تعیین می شود.

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

داستان ها

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

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

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

نسخه

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

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

خریدار (مشتری) می تواند سبد خود را پر کند (مجموعه ای از داستان ها را انتخاب کند)، پس از آن برنامه نویسان تاریخ نهایی اجرای آنها را محاسبه می کنند، یا تاریخی را تعیین می کنند که برنامه نویسان تا آن زمان بودجه را محاسبه می کنند و مشتری آن را جمع آوری می کند. تعداد مورد نیاز داستان برای مبلغ دریافتی.

تکرار

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

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

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

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

یک وظیفه

برای اجرای یک کار، برنامه نویس مسئول آن ابتدا به دنبال یک شریک می گردد، زیرا کد نهایی همیشه توسط دو نفر در یک ماشین نوشته می شود. اگر سؤالاتی در مورد موضوع یا روش‌های پیاده‌سازی مطرح شود، شرکا یک جلسه کوتاه (15 دقیقه‌ای) با مشتری و/یا برنامه‌نویسانی برگزار می‌کنند که در مسائل کدنویسی آگاه هستند که به احتمال زیاد با کد این کار مرتبط است. اجرا

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

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

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

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

تست

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

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

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

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

تو مشکلاتی داری؟

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

اصول XP برای تکامل سریع یک طرح در راستای تغییرات فنی و مرتبط با کسب و کار، منعکس کننده اصول روش شناسی اسکرام و زبان قالب بندی قسمت ها است که توسط وارد کانینگهام توسعه یافته است.

ایده تعیین و برنامه ریزی یک پروژه از نظر امکانات قابل تحقق به کار ایوار یاکوبسون برمی گردد.

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

مدل مارپیچی توسط بری بوهم اولین واکنش به منسوخ شدن مدل آبشار بود. برای مدت طولانیدر تسلط بر فن آوری های قدرتمند، هیچ کس نمی تواند از دیو توماس و همکارانش در Object Technology International که متد JIT را ایجاد کردند، پیشی بگیرد.

ریشه های اصل استعاره به کار رفته در XP را می توان در کتاب های جورج لاکوف و مارک جانسون، به ویژه آخرین اثر آنها Philoslphy in the Flesh یافت. این اصل همچنین توسط ریچارد کوین پیشنهاد شد که استعاره و توسعه نرم افزار را از نظر فلسفه پست مدرن به هم مرتبط می کند.

در نهایت، بسیاری از تاکید XP بر سازماندهی اداری ناشی از کار جیم کاپلین، تام دیمارکو و تیم لیستر است که به تاثیر شرایط محیطی بر کار برنامه نویسان اشاره کردند.

نمونه هایی از اجرای پروژه ها با استفاده از XP

Acxiom: در راه رسیدن به یک هدف مشترک

جی هانولا

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

کاربرد:پایگاه داده مدیریت کمپین

دوره اجرا: 3 سال

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

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

تلاش زیادی برای تست واحد انجام شد زیرا Forte ابزارهای تست اولیه داخلی را ارائه نمی دهد. ما مجبور شدیم خودمان را بسازیم و از آنها برای آزمایش موفقیت آمیز استفاده کنیم. ما اخیراً به زبان برنامه نویسی جاوا روی آورده ایم و اکنون از JUnit به عنوان یک ابزار تست استفاده می کنیم.

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

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

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

"برنامه نویسی افراطی" تیم ما را در شرایط سخت قرار نداد. این روش از رویکردهای توسعه شناخته شده و تا حد زیادی آشنا استفاده می کند. همه با هم کار می کنند و با هم به سمت هدف حرکت می کنند.

دایملر کرایسلر: بهترین تیم جهان

چت هندریکسن

تیم: 15 نفر از جمله 10 برنامه نویس

کاربرد:اتوماسیون کامل محاسبه حقوق و دستمزد

دوره اجرا: 4 سال

کار بر روی پروژه C3 در ژانویه 1995 آغاز شد. شرکت کرایسلر قراردادی با یک شرکت شریک منعقد کرد که بر اساس آن یک تیم توسعه مشترک از هر دو سازمان پروژه را بر عهده گرفتند. شرکای ما یک روش توسعه متمرکز بر استفاده را دنبال کردند رابط کاربری گرافیکیو اتوماسیون تست را نادیده گرفت. نتیجه سیستمی بود که مملو از گرافیک های غیر قابل توجه بود و حقوق را برای اکثر کارمندان به اشتباه محاسبه می کرد. حدود 100 روز طول می کشد تا چنین سیستمی یک لیست حقوق و دستمزد ماهانه ایجاد کند. متوجه شدیم که برنامه ای که نوشتیم واقعاً مورد استفاده قرار نخواهد گرفت.

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

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

این مرحله از اجرای C3 در ماه می 1997 راه اندازی شد، اگرچه ما تاریخ زودتر را پیش بینی کرده بودیم. شکست برنامه های ما دو عامل بود. ابتدا تصمیم گرفتیم فقط اجزای داخلی را جایگزین کنیم سیستم پرداخت. تمام رابط های خارجی دست نخورده باقی ماندند. خروجی مطابقت سیستم جدیدمعلوم شد که اجزای قدیمی بسیار بیشتر است وظیفه چالش برانگیزاز آنچه انتظار داشتیم دوم، ما تصمیم گرفته‌ایم که الزامات ویژه‌ای را در هیچ دوره پرداختی، مانند پردازش W-2، اشتراک سود، یا افزایش کلی افزایش ندهیم. دستمزد. در نتیجه کاری که باید در آبان ماه انجام می شد به فروردین موکول شد.

از زمان راه اندازی سیستم محاسبه پرداخت ماهانه، چندین ویژگی جدید و محاسبه خودکار پرداخت دوهفته ای را اضافه کرده ایم. حقوق و دستمزد گروه پایلوت از مرداد 98 محاسبه شده است و امیدواریم تا آبان 99 برای بقیه کارکنان سیستم کاری داشته باشیم.

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

فورد موتور: ترکیبی منحصر به فرد از کارایی و کیفیت

دان ولز

تیم: 17 نفر، از جمله 12 برنامه نویس

کاربرد:سیستم تحلیل هزینه

دوره اجرا: 6 سال

بخش سیستم های مالی شرکت فورد موتور سیستم تجزیه و تحلیل هزینه و سود خودرو (VCAPS) را توسعه می دهد که گزارش هایی در مورد درآمد تولید، هزینه ها، درآمد خالص و سود تولید می کند. ورودی های سیستم عبارتند از مشخصات محصول مهندسی، هزینه ها و هزینه های ثابت و هزینه های متغیر مانند ساعات کار. VCAPS تمام این داده ها را جمع آوری می کند و گزارش های دقیقی را با تجزیه و تحلیل هزینه تهیه می کند که امکان پیش بینی موثر و تصمیم گیری شرکتی را فراهم می کند. کار بر روی پروژه VCAPS در سال 1993 آغاز شد. با استفاده از VisualWorks و GemStone Smalltalk توسعه یافته است. VCAPS در حال حاضر توسط یک تیم کوچک از افراد نگهداری می شود و به زودی با یک برنامه مدرن تر جایگزین خواهد شد.

هنگام اجرای پروژه VCAPS، باید دو مشکل جدی را حل می کردیم. ابتدا، تحلیلگران می خواستند تغییراتی را در سیستم ایجاد کنند، در حالی که ویژگی های جدیدی را دریافت کردند که قبلاً کار می کرد. نیازها دائماً در حال تغییر بودند و ما نمی‌توانستیم با آنها هماهنگ شویم. ثانیاً محدودیت های خاصی در زمان کارکرد سیستم وجود داشت. در همان زمان، سیستم زمان زیادی را صرف پردازش داده ها کرد و به ورودی دستی دنباله های طولانی نیاز داشت. هر اشتباهی منجر به نیاز به راه اندازی مجدد و از دست دادن زمان گرانبها شد.

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

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

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

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

پس از یک سال و نیم، تعداد خرابی های سیستم به قدری کاهش یافته است که مشتریان و مدیریت ما توانستند ثبات سیستم را به میزان قابل توجهی اعلام کنند. برای ما، این نماد موفقیت اصول XP بود.

سیستم تعرفه: تست هایی که می توانید بخوانید

راب می

تیم:سه توسعه دهنده

کاربرد:سیستم محاسبه تعرفه حمل و نقل

دوره اجرا: 3 ماه

سیستم تعرفه بخشی از یک پروژه بزرگ است که با استفاده از SmallTalk/GemStone در یکی از شرکت های بزرگ بین المللی متخصص در حمل و نقل کانتینری اجرا شده است. رویکرد XP این امکان را به وجود آورد که تمامی مراحل توسعه این زیرسیستم، از مفهوم تا راه اندازی، طی سه ماه توسط سه نفر طی شود. نتیجه به طور قابل ملاحظه ای پایدار و نگهداری آسان بود.

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

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

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

استقبال از تغییر با برنامه نویسی شدید، کنت بک. کامپیوتر، اکتبر 1999، صص. 70-77، تجدید چاپ با اجازه، حق چاپ IEEE، 1999، کلیه حقوق محفوظ است.

برنامه نویسی شدید (XP) یک روش توسعه نرم افزار ساده شده برای تیم های توسعه کوچک تا متوسط ​​است که یک محصول نرم افزاری با الزامات نامشخص یا به سرعت در حال تغییر می سازند.

اهداف اصلی XP هستند افزایش اعتماد مشتری به محصول نرم افزاری با ارائه شواهد واقعی از موفقیت توسعه فرآیند توسعه و کاهش شدید زمان توسعه محصول . در عین حال، XP روی به حداقل رساندن اشکالات در مراحل اولیه توسعه متمرکز شده است. این امکان دستیابی را فراهم می کند حداکثر سرعتانتشار محصول نهایی و امکان صحبت در مورد قابل پیش بینی بودن کار را فراهم می کند. تقریباً تمام تکنیک های XP با هدف بهبود کیفیت محصول نرم افزاری انجام می شود.

اصول XP

اصول اصلی عبارتند از:

• تکرار.توسعه در تکرارهای کوتاه در حضور یک رابطه فعال با مشتری انجام می شود. تکرارها به این ترتیب کوتاه هستند، مدت زمان توصیه شده 2-3 هفته و حداکثر 1 ماه است. در یک تکرار، گروهی از برنامه نویسان باید چندین ویژگی سیستم را پیاده سازی کنند که هر کدام در یک داستان کاربر توضیح داده شده است. داستان های کاربر (UI) در این مورد اطلاعات اولیه ای هستند که بر اساس آن ماژول ایجاد می شود. آنها از موارد استفاده (UTs) متمایز هستند. شرح PI کوتاه است - 1-2 پاراگراف، در حالی که PI معمولاً با جزئیات کافی، با جریان های اصلی و جایگزین توضیح داده می شود و با یک مدل تکمیل می شود. UI ها توسط خود کاربران نوشته می شوند که در XP جزئی از تیم هستند، بر خلاف رابط های کاربری که توسط تحلیلگر سیستم توضیح داده شده است. عدم رسمیت بخشیدن به شرح داده های ورودی پروژه در XP با گنجاندن فعالانه مشتری در فرآیند توسعه به عنوان عضو کامل تیم جبران می شود.
• سادگی راه حل هااولین ساده ترین راه حل کاری اتخاذ شده است. ماهیت شدید روش با درجه بالاخطر تصمیم به دلیل سطحی بودن تجزیه و تحلیل و برنامه زمانی سفت و سخت. حداقل مجموعه ای از توابع اصلی سیستم در اولین و هر تکرار بعدی اجرا می شود. عملکرد در هر تکرار گسترش می یابد.
• توسعه فشرده توسط تیم های کوچک(بیشتر از 10 نفر) و برنامه نویسی جفتی(زمانی که دو برنامه نویس با هم در یک محل کار مشترک کد ایجاد می کنند)، ارتباط فعال در گروه و بین گروه ها. همه اینها با هدف تشخیص زودهنگام ممکن مشکلات (هم خطاها و هم مهلت های از دست رفته) انجام می شود. برنامه نویسی جفتی با هدف حل مشکل تثبیت پروژه انجام می شود. هنگام استفاده از روش XP، به دلیل خروج برنامه نویسی که نمی تواند برنامه کاری فشرده را تحمل کند، خطر زیادی از دست دادن کد وجود دارد. در این مورد، برنامه نویس دوم از جفت نقش "وارث" کد را بازی می کند. همچنین مهم است که چگونه گروه ها در فضای کاری توزیع می شوند - XP از یک فضای کاری باز استفاده می کند که به معنای دسترسی سریع و رایگان برای همه به همه است.
• بازخورد مشتری، که نماینده آن در واقع درگیر فرآیند توسعه است.
• شجاعت کافیو تمایل به ریسک کردن

ترفندهای XP (تمرین)

معمولا XP با مجموعه ای از 12 قانون (عمل) مشخص می شود که برای دستیابی به آن باید رعایت شود. نتیجه خوب. هیچ یک از روش ها اساساً جدید نیستند، اما آنها در XP گرد هم آمده اند.

1. برنامه ریزی فرآیندکل تیم توسعه دور هم جمع می شوند، تصمیم جمعی در مورد اینکه کدام ویژگی های سیستم در تکرار بعدی پیاده سازی می شود، گرفته می شود. پیچیدگی اجرای هر ویژگی توسط خود برنامه نویسان تعیین می شود.
2. تعامل نزدیک با مشتری.نماینده مشتری باید عضو تیم XP باشد. او رابط کاربری را می نویسد، داستان هایی را که در یک تکرار خاص پیاده سازی می شوند انتخاب می کند و به سوالات مربوط به کسب و کار پاسخ می دهد. نماینده مشتری باید باشد کارشناس در حوزه موضوع خودکار داشتن بازخورد دائمی از نماینده مشتری ضروری است.
3. قوانین کلی نامگذاری سیستمقراردادهای خوب نامگذاری سیستم سهولت نامگذاری کلاس ها و متغیرها تیم توسعه باید قراردادهای نامگذاری یکسانی داشته باشد.
4. معماری سادههر ویژگی سیستم باید تا حد امکان ساده پیاده سازی شود. برنامه نویسان تیم XP با این شعار کار می کنند: "هیچ چیز بیشتر!". اولین راه حل کار ساده اتخاذ شده است، سطح مورد نیاز از عملکرد در حال حاضر در حال اجرا است. این باعث صرفه جویی در وقت برنامه نویس می شود.
5. Refactoring.این یک بهینه سازی کد موجود به منظور ساده سازی آن است، چنین کاری باید به طور مداوم انجام شود. با شفاف نگه داشتن کد و تعریف عناصر آن فقط یک بار، برنامه نویسان تعداد اشکالاتی را که باید بعداً برطرف شوند، کاهش می دهند. هنگام پیاده سازی هر ویژگی جدید سیستم، برنامه نویس باید در نظر بگیرد که آیا کد موجود را می توان ساده کرد و چگونه به پیاده سازی ویژگی جدید کمک می کند. علاوه بر این، شما نمی توانید refactoring را با طراحی ترکیب کنید: اگر ایجاد کنید کد جدید، بازسازی مجدد باید به تعویق بیفتد.
6. برنامه نویسی جفتیهمه برنامه نویسان باید به صورت جفت کار کنند: یکی کد را می نویسد، دیگری نگاه می کند. بنابراین، لازم است گروهی از برنامه نویسان را در یک مکان قرار دهیم. XP در تیم های توزیع نشده از برنامه نویسان و کاربران بهترین کار را دارد.
7. 40 ساعت کار در هفتهبرنامه نویس نباید بیش از 8 ساعت در روز کار کند. نیاز به اضافه کاری یک شاخص واضح از یک مشکل در آن منطقه خاص توسعه است. یافتن علل اضافه کاری و رفع سریع آنها یکی از قوانین اساسی است.
8. مالکیت کد جمعیهر برنامه نویسی در تیم باید به کد هر قسمت از سیستم دسترسی داشته باشد و حق تغییر در هر کدی را داشته باشد. قانون اجباری: اگر برنامه نویسی تغییراتی ایجاد کرده باشد و پس از آن سیستم به درستی کار نکند، این برنامه نویس است که باید خطاها را اصلاح کند.
9. استانداردهای کدگذاری یکنواختاستانداردهای کدنویسی برای پشتیبانی از روش های دیگر مورد نیاز است: به اشتراک گذاری کد، برنامه نویسی جفتی و refactoring. بدون یک استاندارد واحد، حداقل انجام این شیوه ها دشوارتر است، اما در واقعیت به طور کلی غیرممکن است: گروه در حالت کمبود دائمی زمان کار خواهد کرد. تیم برای مدت طولانی روی این پروژه کار کرده است. مردم می آیند و می روند. هیچ کس به تنهایی کد نمی نویسد و کد متعلق به همه است. همیشه لحظاتی وجود خواهد داشت که درک و تصحیح کد شخص دیگری ضروری است. توسعه‌دهندگان کدهای تکراری را حذف می‌کنند، کلاس‌های دیگران را تجزیه و تحلیل و بهبود می‌بخشند، و غیره. با گذشت زمان، نمی‌توان تشخیص داد که نویسنده یک کلاس خاص کیست. بنابراین، همه باید از استانداردهای رایج کدنویسی - قالب بندی کد، نامگذاری کلاس، متغیر، نامگذاری ثابت، سبک نظرات پیروی کنند. موارد فوق به این معنی است که همه اعضای تیم باید در مورد استانداردهای کدگذاری مشترک به توافق برسند. مهم نیست، اما همه موظف به اطاعت از آنها هستند.
10. نسخه های کوچک.حداقل تکرار یک روز و حداکثر یک ماه است. هرچه تعداد دفعات انتشار بیشتر باشد، نقص های بیشتری در سیستم آشکار می شود. اولین نسخه ها به شناسایی کاستی ها در مراحل اولیه کمک می کند، سپس عملکرد سیستم بر اساس UI گسترش می یابد. از آنجایی که کاربر از اولین نسخه در فرآیند توسعه گنجانده شده است، سیستم را ارزیابی کرده و یک داستان کاربر و نظرات خود را صادر می کند. بر این اساس، تکرار بعدی مشخص می شود، یعنی نسخه جدید چه خواهد بود. همه چیز در مورد XP در مورد ارائه بازخورد مداوم به کاربران است.
11. یکپارچه سازی مداومادغام بخش‌های جدید سیستم باید تا حد امکان، حداقل هر چند ساعت یک‌بار اتفاق بیفتد. قانون اساسی یکپارچه سازی به شرح زیر است: در صورتی که همه آزمون ها با موفقیت پشت سر گذاشته شوند، می توان ادغام را انجام داد. اگر تست ها موفق نشدند، برنامه نویس باید یا اصلاحاتی انجام دهد و سپس اجزای سیستم را یکپارچه کند یا اصلا آنها را یکپارچه نکند. این قانون سفت و سخت و بدون ابهام است. اگر حداقل یک خطا در قسمت ایجاد شده از سیستم وجود داشته باشد، نمی توان یکپارچه سازی را انجام داد. ادغام مکرر به شما امکان می دهد به جای صرف یک هفته برای مونتاژ، سریعتر یک سیستم آماده را دریافت کنید.
12. آزمایش کردن.بر خلاف بسیاری از متدولوژی های دیگر، تست در XP یکی از مهم ترین مؤلفه ها است. رویکرد افراطی این را فرض می کند تست ها قبل از نوشتن کد نوشته می شوند . هر ماژول باید یک آزمون واحد داشته باشد - یک آزمون برای این ماژول. بنابراین، XP هنگام اضافه کردن عملکرد، آزمایش رگرسیون، "کیفیت غیر افتضاح" را انجام می دهد. اکثر خطاها در مرحله کدگذاری تصحیح می شوند. تست ها توسط خود برنامه نویسان نوشته می شوند، هر کدام از آنها حق دارند برای هر ماژول تست بنویسند. اصل مهم دیگر: تست کد را تعیین می کند و نه برعکس (توسعه مبتنی بر تست)، یعنی یک قطعه کد در مخزن قرار می گیرد اگر و فقط در صورتی که همه تست ها با موفقیت سپری شده باشند، در غیر این صورت این تغییر کد رد می شود.

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

و دیگران.

نام متدولوژی از ایده کاربرد مفید گرفته شده است روش های سنتیو شیوه های توسعه نرم افزار، آنها را به یک سطح "افراطی" جدید ارتقا می دهد. بنابراین، به عنوان مثال، تمرین انجام یک بازنگری کد، که شامل بررسی کد نوشته شده توسط برنامه نویس دیگر توسط یک برنامه نویس است، در نسخه "extreme" "برنامه نویسی جفت" است، زمانی که یک برنامه نویس در حال کدنویسی است، و شریک او در در همان زمان به طور مداوم کدهای جدید نوشته شده را بررسی می کند.

یوتیوب دایره المعارفی

1 / 5

برنامه نویسی شدید (XP) - تکنیک های اساسی

هکسلت وبینار شماره 6: برنامه نویسی شدید

نکات زندگی چرا در مسابقات برنامه نویسی شرکت کنیم؟

032. برنامه نویسی جفت - سرگئی برژنوی

Extreme Programming Channel v. 2.0

زیرنویس

ترفندهای اساسی XP

دوازده تکنیک اساسی برنامه نویسی افراطی (طبق ویرایش اول کتاب برنامه نویسی افراطی توضیح داده شده است) را می توان به چهار گروه تقسیم کرد:

• چرخه بازخورد کوتاه (بازخورد در مقیاس ظریف)
  • توسعه از طریق آزمایش (توسعه مبتنی بر آزمایش)
  • بازی برنامه ریزی
  • مشتری همیشه آنجاست (کل تیم، مشتری در محل)
  • برنامه نویسی جفتی
• فرآیند پیوسته، نه دسته ای
  • ادغام مداوم
  • Refactoring (بهبود طراحی، Refactoring)
  • انتشار کوچک مکرر
• تفاهمی که بین همه مشترک است
  • سادگی
  • استعاره سیستم
  • مالکیت کد جمعی یا الگوهای طراحی انتخابی (مالکیت الگوهای جمعی)
  • استاندارد کدنویسی یا قراردادهای کدگذاری
• تامین اجتماعی برنامه نویس (رفاه برنامه نویس):
  • هفته کاری 40 ساعته (سرعت پایدار، هفته چهل ساعت)

آزمایش کردن

XP شامل نوشتن تست های خودکار است (کد برنامه ای که به طور خاص برای آزمایش منطق برنامه دیگری نوشته شده است کد برنامه). توجه ویژه ای به دو نوع آزمایش می شود:

• تست واحد ماژول ها؛

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

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

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

بازی برنامه ریزی

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

مشتری همیشه آنجاست

"مشتری" در XP کسی نیست که صورتحساب ها را پرداخت می کند، بلکه کاربر نهایی محصول نرم افزاری است. XP ادعا می کند که مشتری باید همیشه در تماس باشد و برای سوالات در دسترس باشد.

برنامه نویسی جفتی

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

یکپارچه سازی مداوم

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

Refactoring

Refactoring تکنیکی برای بهبود کد بدون تغییر عملکرد آن است. XP به این معنی است که پس از نوشتن کد، تقریباً به طور قطع چندین بار در طول یک پروژه دوباره تکرار می شود. توسعه دهندگان XP بی رحمانه کدهای نوشته شده قبلی را به منظور بهبود آن دوباره کار می کنند. به این فرآیند refactoring می گویند. عدم پوشش آزمایشی باعث رد ریفکتورینگ به دلیل ترس از شکستن سیستم می شود که منجر به تخریب تدریجی کد می شود.

انتشار کوچک مکرر

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

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

سهولت طراحی

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

استعاره سیستم

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

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

انتخاب یک استعاره خوب درک نحوه عملکرد سیستم را برای تیم توسعه آسان تر می کند. گاهی اوقات انجام این کار آسان نیست.

استانداردهای رمزگذاری

تمامی اعضای تیم باید در حین کار الزامات استانداردهای کدگذاری مشترک را رعایت کنند. در نتیجه:

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

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

مالکیت جمعی

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