ارسال کار خوب خود را در پایگاه دانش ساده است. از فرم زیر استفاده کنید

کار خوببه سایت ">

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

ارسال شده در http://www.allbest.ru/

محتوا

• معرفی
• 1. XP چیست؟
• 3.1 تکنیک های اساسیXP
• 4. مزایا و معایب
• 5. سابقه استفاده
• نتیجه

معرفی

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

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

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

1. XP چیست؟

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

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

XP با استفاده از چرخه های توسعه بسیار کوتاه، بازخورد سریع، واقعی و دائمی ارائه می دهد.

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

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

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

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

XP بر اساس یک فرآیند طراحی در حال تکامل است که به اندازه خود سیستم دوام می آورد.

XP بر اساس تعامل نزدیک برنامه نویسان با رایج ترین مهارت ها و قابلیت ها است.

XP بر اساس تکنیک هایی است که هم غریزه کوتاه مدت برنامه نویسان فردی و هم علایق بلند مدت پروژه را به عنوان یک کل برآورده می کند.

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

تکنیک XP برای کار بر روی پروژه هایی طراحی شده است که دو تا ده برنامه نویس می توانند روی آنها کار کنند که توسط چارچوب سفت و سخت محیط رایانه موجود محدود نشده اند و در آن همه کار لازممرتبط با آزمایش را می توان در یک روز کامل کرد.

2. چگونه برنامه نویسی شدید را شروع کنیم

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

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

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

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

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

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

3. تکنیک های XP

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

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

· افراد درگیر در پروژه و ارتباطات آنها مهمتر از فرآیندها و ابزارها است.

· یک برنامه کاری مهمتر از مستندات جامع است.

· همکاری با مشتری مهمتر از مذاکره درباره جزئیات قرارداد است.

· انجام تغییرات مهمتر از دنبال کردن برنامه ها است.

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

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

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

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

· زندهبرنامه ریزی (برنامه ریزیبازی)

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

برنج.1 نمودار گردش کار XP

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

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

· استعاره (استعاره) سیستم های

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

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

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

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

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

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

· توسعه ازبر رویاساسآزمایش کردن (تست- راندهتوسعه)

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

در XP توجه ویژهبر دو نوع آزمایش تمرکز دارد:

تست واحد؛

ب آزمون پذیرش

نرم افزار برنامه نویسی افراطی

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

تست‌های پذیرش تضمین می‌کنند که سیستم واقعاً همانطور که تبلیغ می‌شود عمل می‌کند. علاوه بر این، تست های پذیرش به شما امکان می دهد عملکرد صحیح محصول در حال توسعه را بررسی کنید.

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

· مقدار ثابتدر حال پردازش (بازسازی)

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

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

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

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

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

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

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

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

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

· مقدار ثابتادغام (مداومادغام)

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

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

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

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

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

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

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

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

· روشن شدنمشتریvفرمان (بر- سایتمشتری)

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

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

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

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

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

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

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

· تغییرقوانینبرنیاز (فقطقوانین)

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

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

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

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

بازخورد در مقیاس خوب

o توسعه آزمایش محور

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

o مشتری همیشه نزدیک است (کل تیم، مشتری در محل)

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

فرآیند پیوسته، نه دسته ای

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

o Refactoring (بهبود طراحی، Refactor)

o انتشارهای کوچک مکرر

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

o سادگی (طراحی ساده)

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

o مالکیت کد جمعی یا الگوهای انتخابی طراحی (مالکیت الگوهای جمعی)

o استاندارد کدنویسی یا قراردادهای کدگذاری

رفاه برنامه نویس:

o 40 ساعت کاری در هفته (سرعت پایدار، چهل ساعت در هفته)

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

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

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

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

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

در یک موقعیت ایده آل، یک بازی برنامه ریزی شامل یک مشتری و یک برنامه نویس باید هر 3-6 هفته یکبار، قبل از شروع تکرار توسعه بعدی، انجام شود. این باعث می شود که تنظیمات بر اساس موفقیت ها و شکست های تکرار قبلی آسان شود.

4. مزایا و معایب

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

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

5. سابقه استفاده

XP به عنوان مجموعه ای از تکنیک های توصیف شده برای اولین بار در طول کار بر روی پروژه C3 (سیستم جامع جبران خسارت کرایسلر، توسعه سیستمی برای حسابداری مزایای کارکنان برای دایملر کرایسلر) استفاده شد. از 20 شرکت کننده در این پروژه، 5 نفر (از جمله 3 نویسنده اصلی XP ذکر شده در بالا) در طول خود پروژه و بعداً 3 کتاب و مقدار زیادیمقالات در XP داده‌های زیر چالش‌های برخی از تکنیک‌های XP را هنگامی که برای پروژه‌های نسبتاً پیچیده اعمال می‌شوند، نشان می‌دهد.

این پروژه از ژانویه 1995 آغاز شد. از مارس 1996، پس از گنجاندن کنت بک، با استفاده از XP اجرا شد. در این زمان ، او قبلاً از بودجه و برنامه ریزی برای اجرای مرحله ای عملکردها فراتر رفته بود. تیم توسعه کوچک شد و حدود نیم سال پس از آن، پروژه با موفقیت توسعه یافت. در آگوست 1998، یک نمونه اولیه ظاهر شد که می توانست به حدود 10000 کارمند خدمت کند. در ابتدا انتظار می رفت این پروژه در اواسط سال 1999 تکمیل شود و نرم افزار حاصل برای مدیریت پرداخت ها به 87000 کارمند شرکت استفاده شود. در فوریه 2000 پس از 4 سال اجرای XP به دلیل عدم انطباق کامل با جدول زمانی و بودجه متوقف شد. این نرم افزار هرگز برای کار با داده های بیش از 10000 کارمند استفاده نشده است، اگرچه نشان داده شده است که با داده های 30000 کارمند شرکت مقابله می کند. فردی که نقش مشتری در پروژه را ایفا می کرد، پس از چند ماه انجام چنین کاری، ناتوان از تحمل بار استعفا کرد و تا پایان پروژه جایگزین مناسبی دریافت نکرد.

نتیجه

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

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

ارسال شده در Allbest.ru

اسناد مشابه

تجزیه و تحلیل مراحل و ویژگی های توسعه یک مدل بهینه و کاربردی ARIS - محصول نرم افزاری از IDS Scheer برای مدل سازی فرآیندهای تجاری شرکت. مطالعه مفاهیم اساسی، روش ها و رویکردهای برنامه نویسی افراطی.

تست، اضافه شده در 06/04/2011


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

ارائه اضافه شده در 10/13/2013


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

آموزش، اضافه شده در 2013/10/26


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

ارائه اضافه شده در 2014/04/30


کدهای ماشین و اسمبلر. اولین زبان های برنامه نویسی سطح بالا. زبان برنامه نویسی فرترن مزایا و معایب ALGOL. نرم افزار علمی و حسابداری. اصول اولیه ای که هنگام ایجاد زبان برنامه نویسی Basic رعایت شد.

مقاله ترم اضافه شده در 2014/06/21


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

مقاله ترم اضافه شده 12/14/2012


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

ارائه در 2013/08/14 اضافه شد


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

مقاله ترم، اضافه شده در 2010/02/28


ابزارهای توسعه نرم افزار مدرن برای SUTP. زبان های برنامه نویسی جهانی و مقایسه آنها با سیستم های اسکادا توسعه نرم افزار با استفاده از چند کانال مبدل های اندازه گیریШ9327.

پایان نامه، اضافه شده 07/13/2011


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

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

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

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

طرح انتشار

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

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

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

جلسه ایستاده

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

سادگی

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

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

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

مشتری در سایت

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

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

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

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

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

تغییر سمت ها

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

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

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

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

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

ادغام مکرر

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

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

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

نتیجه

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

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

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

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

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

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

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

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

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

چرخه شدید

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

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

در نتیجه تغییر مداوم الزامات، اصل دیگری دنبال می شود - تصمیم گیری دیرهنگام.

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

حقوق و نقش ها

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

مشتری

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

• اصلاح تاریخ انتشار نسخه های محصول؛
• تصمیم گیری در مورد اجزای برنامه ریزی شده برنامه؛
• هزینه تخمینی هر جزء عملکردی را بدانید.
• اتخاذ تصمیمات مهم تجاری؛
• دانستن وضعیت فعلیسیستم های؛
• نیازهای سیستم را زمانی که واقعا مهم است تغییر دهید.

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

توسعه دهنده

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

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

نقش ها در یک نقش

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

سمت مشتری

داستان ساز- یک متخصص در حوزه موضوعی که توانایی بیان و تشریح الزامات سیستم در حال توسعه را دارد. این شخص یا گروهی از افراد مسئول نوشتن داستان های کاربری و رفع سوء تفاهمات از برنامه نویسان هستند.

گیرنده- شخصی که عملکرد صحیح سیستم را کنترل می کند. دستور خوب موضوع... مسئولیت ها شامل نوشتن آزمون های پذیرش است.

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

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

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

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

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

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

نقش های بیرونی

مشاور- یک متخصص با مهارت های فنی خاص برای کمک به توسعه دهندگان در انجام کارهای دشوار. معمولا از بیرون جذب می شود.

قوانین برنامه نویسی شدید

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

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

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

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

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

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

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

جلسه CRC

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

هر کارت CRC یک نمونه شی است. کلاس شی را می توان در بالا، مسئولیت ها در سمت چپ، تعاملات در سمت راست نوشت. ما می گوییم "می توان نوشت" زیرا زمانی که جلسه CRC در حال انجام است، شرکت کنندگان معمولاً نیاز دارند عدد کوچککارت هایی با نام کلاس ها و نیازی به پر کردن کامل آنها نیست.

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

برای نظم دادن به همه چیز، اغلب از محدودیت تعداد دو نفر که به طور همزمان با هم در تعامل هستند استفاده می شود.

مشتری

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

داستان های کاربرتوسط مشتری با کمک توسعه دهندگان نوشته شده است. مشتری کمک می کند تا مطمئن شود که اکثر عملکردهای سیستم مورد نظر توسط داستان کاربر پوشش داده می شود.

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

ساده ترین راه حل را انتخاب کنید

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

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

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

تست های عملکردی

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

ادغام مکرر

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

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

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

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

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

داستان های کاربر و تست های عملکردی ناموفق به وظایف تقسیم می شوند. وظایف روی کارت ها ثبت می شوند. این کارت ها طرح تفصیلی برای تکرار هستند. طول هر کار باید بین 1 تا 3 روز ایده آل باشد.

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

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

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

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

تکرار

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

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

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

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

وظایف را تغییر دهید

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

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

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

هنگام شروع یک کار جدید تکرارهاهر توسعه دهنده باید به وظیفه جدید... جفت شدن به غلبه بر مشکل سازگاری کمک می کند (به این معنی که یک توسعه دهنده جدید می تواند با یک توسعه دهنده با تجربه در این زمینه جفت شود).

این عمل همچنین ایده های جدید و بهبود کد را تحریک می کند.

بهینه سازی را برای بعد ذخیره کنید

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

کاری کنید که کار کند، سپس آن را درست کنید، سپس آن را سریع کنید.

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

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

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

بی رحمانه Refactor!

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

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

طرح انتشار

طرح انتشار در جلسه برنامه ریزی انتشار تهیه می شود. Release Plans نمایی از کل پروژه را توصیف می کند و بعداً برای برنامه ریزی تکرار استفاده می شود.

مهم این است که افراد فنی تصمیمات فنی بگیرند و افراد تجاری تصمیمات تجاری را بگیرند. برنامه ریزی انتشار مجموعه ای از قوانین را تعریف می کند که به هر کس اجازه می دهد تصمیمات خود را بگیرد. این قوانین روشی را برای توسعه یک برنامه کاری که همه را راضی کند، تعریف می کند.

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

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

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

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

انتشارات مکرر

توسعه دهندگان باید تا حد امکان نسخه های سیستم را برای کاربران (یا آزمایش کنندگان بتا) منتشر کنند.

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

راه حل آزمایشی

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

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

جلسه ایستاده

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

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

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

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

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

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

همیشه System Metaphor را انتخاب کنید - یک مفهوم ساده و ساده برای اعضای تیم که همه چیزها را به یک نام صدا کنند. برای درک سیستم و اجتناب از کدهای تکراری، نحوه نامگذاری اشیاء بسیار مهم است. اگر بتوانید حدس بزنید که نام یک شی در سیستم چیست (اگر می دانید چه کاری انجام می دهد) و واقعاً به این نام خوانده می شود، در زمان و تلاش بسیار صرفه جویی خواهید کرد. یک سیستم نامگذاری برای اشیاء خود ایجاد کنید تا همه اعضای تیم بتوانند بدون دانش خاصی از سیستم از آن استفاده کنند.

تست های واحد

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

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

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

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

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

داستان کاربر

داستان کاربر (چیزی شبیه داستان کاربر) توضیحی در مورد نحوه عملکرد سیستم است. هر User Story بر روی یک کارت نوشته شده است و نشان دهنده بخشی از عملکرد سیستم است که از دیدگاه مشتری منطقی است. فرم - یک یا دو پاراگراف متن که برای کاربر قابل درک است (خیلی فنی نیست).

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

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

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

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

سرعت پروژه

سرعت پروژه (یا به سادگی سرعت) معیاری است از سرعت انجام کار در پروژه شما.

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

در طول برنامه ریزی انتشار، از سرعت پروژه برای تخمین تعداد استوری کاربر استفاده می شود.

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

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

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

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

وقتی خطایی پیدا شد

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

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

شما به آن نیاز ندارید

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

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

توجیه اقتصادی کامل کلیه اقدامات - فقط آنچه مشتری نیاز دارد انجام می شود و منجر به زیان پروژه نمی شود.

شکل گیری معماری پایه در اسرع وقت.

استفاده از معماری کامپوننت

نمونه سازی، توسعه تدریجی و آزمایش.

ارزیابی منظم از وضعیت فعلی

مدیریت تغییر، توسعه مداوم تغییرات از خارج از پروژه.

روی ایجاد محصولی تمرکز کنید که در یک محیط واقعی کار کند.

تعهد به کیفیت.

انطباق فرآیند با نیازهای پروژه.

برنامه نویسی افراطی

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

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

افراد درگیر در پروژه و ارتباطات آنها مهمتر از فرآیندها و ابزارها هستند.

یک برنامه کاری مهمتر از مستندات جامع است.

همکاری با مشتری مهمتر از مذاکره درباره جزئیات قرارداد است.

انجام تغییرات مهمتر از دنبال کردن برنامه هاست.

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

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

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

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

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

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

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

				تست
		استفاده از		اسکریپت ها
			داستان جدید
	الزامات		استفاده از
			سرعت پروژه
	استعاره		طرح نسخه
		برنامه ریزی		تکرار	در حال دریافت	کم اهمیت
معماری				آخرین
						خوب
						کاربران
غیر قابل اعتماد			مطمئن	تکرار جدید

"پرتاب کردن" محلول

شکل 15. نمودار گردش کار در XP.

تغییرات مکرر نسخه (نسخه های کوچک)

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

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

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

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

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

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

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

Refactoring

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

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

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

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

مالکیت جمعی

V هر زمانی که هر یک از اعضای تیم می تواند هر بخشی از کد را تغییر دهد. هیچ کس نباید حوزه مسئولیت خود را داشته باشد، کل تیم به طور کلی مسئول همه کدها هستند.

ادغام مداوم

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

40 ساعت کار در هفته

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

گنجاندن مشتری در تیم(مشتری در محل)

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

استفاده از کد به عنوان وسیله ارتباطی

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

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

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

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

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

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

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

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

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

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

این پروژه از ژانویه 1995 آغاز شد. از مارس 1996، پس از گنجاندن کنت بک، با استفاده از XP اجرا شد. در این زمان ، او قبلاً از بودجه و برنامه ریزی برای اجرای مرحله ای عملکردها فراتر رفته بود. تیم توسعه کوچک شد و حدود نیم سال پس از آن، پروژه با موفقیت توسعه یافت. در آگوست 1998، یک نمونه اولیه ظاهر شد که می توانست به حدود 10000 کارمند خدمت کند. در ابتدا انتظار می رفت این پروژه در اواسط سال 1999 تکمیل شود و نرم افزار حاصل برای مدیریت پرداخت ها به 87000 کارمند شرکت استفاده شود. در فوریه 2000 پس از 4 سال اجرای XP به دلیل عدم انطباق کامل با جدول زمانی و بودجه متوقف شد. این نرم افزار هرگز برای کار با داده های بیش از 10000 کارمند استفاده نشده است، اگرچه نشان داده شده است که با داده های 30000 کارمند شرکت مقابله می کند. فردی که نقش مشتری در پروژه را ایفا می کرد، پس از چند ماه انجام چنین کاری، ناتوان از تحمل بار استعفا کرد و تا پایان پروژه جایگزین مناسبی دریافت نکرد.

ادبیات برای سخنرانی 3

دبلیو رویس. مدیریت پروژه برای توسعه نرم افزار م.: لری، 2002.

A. Jacobson، G. Booch، J. Rambeau. فرآیند توسعه نرم افزار یکپارچه SPb.: پیتر، 2002.

کرول، روح RUP. www-106.ibm.com/developerworks/rational/library/ محتوا / RationalEdge / dec01 / TheSpiritoftheRUPDec01.pdf

ک. بک. برنامه نویسی افراطی SPb.: پیتر، 2002.

http://www.agilemanifesto.org/

K. Beck, et. al. کرایسلر به سمت "Extremes" می رود. محاسبات توزیع شده، 10/1998.

الف. کاکبرن. انتخاب روش شناسی پروژه نرم افزار IEEE، 04/2000.

ال. ویلیامز، آر. آر. کسلر، دبلیو کانینگهام، آر. جفریس. تقویت کیس برای برنامه نویسی زوجی. نرم افزار IEEE 4/2000.

جی. کیفر. برنامه نویسی شدید برای توسعه نرم افزار قابل اعتماد مضر تلقی می شود. گزارش فنی AVOCA، 2002.

موجود به عنوان http://www.avoca-vsm.com/Dateien-Download/ExtremeProgramming.pdf.