\documentclass{book}
\usepackage{zref-perpage}
\zmakeperpage{footnote}
\usepackage{xepersian}
%\settextfont[Scale=1]{B Nazanin}
\title{به نام خداوند               بخشنده مهربان\\
اصطلاح چابکی  $(Agility)$ در مهندسی  نرم‌افزار      }

%\lr{habibe.shafiei77@gmail.com}}
\begin{document}

\maketitle
\tableofcontents
\newpage
\chapter{ روند پیدایش فرآیند توسعه چابک نرم‌افزار }
\section{مقدمه}
ورود بیانیه    \lr{agile}، تغییرات بی‌نظیری را در زمینه مهندسی نرم‌افزار، به ارمغان آورد. به راستی تغییراتی که این بیانیه به وجود آورد، بر نوع خود کاملاً بی‌نظیر بود. این رشد به آسانی حاصل شد. بنابراین خیلی از کارها مسئولیت ایجاد همبستگی مباحث فعلی \lr{agile} را به عهده گرفته‌اند. مانند هر قانون نوع ظهور، سال‌های اولیه تولید \lr{agile} ، این قانون، با طرفداران کم و شکاکیت زیادی همراه بود دسته‌ای از متدها ظاهر گردیدند که برای تغییر دادن درجه‌ها \LTRfootnote{degree} به اصول  \LTRfootnote{tenets} به هم پیوسته بودند. 

این‌ها شامل  \lr{lean  software  development},   \lr{scrum} , \lr{XP(extreme programing)}  ,\lr{FDD (feature - driven  development)}  و متدولوژی‌های \lr{Crystal}  می‌باشند. در حالت کلی، تمامی این متدها، سعی می‌کنند که شما را به قانون اصلی بیانیه چابکی، ارجاع دهند. در ابتدا یک حرکت مشخص به سمت توسعه شریکی وجود داشت. ثانیاً، غالب ذهنی برای کمینه کردن فعالیت‌های غیرلازم(با توجه به مستندسازی‌هایی که بیهوده انجام می‌شد) مورد حمایت قرار گرفت. سوماً، مشتری‌ها با اینکه در حاشیه توسعه نرم‌افزار بودند اما به خوبی در مورد سیر تکاملی توسعه یک سیستم یا نرم‌افزار ، راهنمایی شده بودند. چهارماً، حقیقتی وجود داشت که این حقیقت جزئی از توسعه نرم‌افزار بود و آن حقیقت تمایل ذاتی برای کنترل کردن تغییرات بود. پس از کلی بحث درباره ویژگی‌های منحصر بفرد متدهای پیشنهادی، احتیاج به داشتن یک راه متعادل، برنامه‌نویسی وظیفه‌ای            \lr{(forth)}  و بحث به سمت متدهای چابک       \lr{(agile)}    و مبتنی بر طرح     \lr{(plan -driven)}    انتقال یافت. در زمان حال، بیشتر توجهات به سمت موضوعاتی وابسته به مدیریت پروژه‌های واقعی، برنامه‌ریزی چابک، کنترل، تخمین، جریان مختصر رویدادها با استفاده از برنامه‌نویسی وظیفه‌ای و \lr{six~-~sigma} معطوف است. خیلی از این ایده‌ها، روش‌هایی را ایجاد  کرده‌اند که ادعا شده که این روش‌ها مؤثرند در حالی که خروجی واقعی، ضعیف است. تحقیقات اخیر صورت گرفته روی  \lr{agile}، بر روی موضوعاتی که مربوط به پذیرش متدهای \lr{agile} هستند، کاملاً قابل دریافت می2باشند. در تحقیقات دیگر، جنبه‌های مختلف پویای سیستم مانند     \lr{trust} ، \lr{self organization}   و ارتباطات و نیز نتایج توسعه آزمایش‌محور                 \lr{(test-driven)}، پذیرش و موضوعات قبلی، چالش‌های پیاده­سازی \lr{agile}  در تنظیمات توزیع شده و مانند اینها بررسی گردیده‌اند. با وجود تحقیقات فراوان در مورد توسعه چابک نرم‌افزار و شاخه‌هایش، احساس می‌شود  که یک سکوی متحد که بین جریانات نامتناجس ارتباط ایجاد کند، وجود ندارد. کارهای دیگری به منظور منظم کردن قانون‌های غیرمبهم و مفید توسعه چابک نرم‌افزار، انجام شده‌اند. 

\section{یک دید کلی بر توسعه چابک نرم­افزار}
\subsection{چابکی و اصول چابک}
بر اساس قانون‌‌های چابک، توسعه­دهندگان نرم‌افزار، هزینه کسب و کار را از طریق تحویل محصولات در زمان کم به مشتری، بدست می‌آورند. این قانون ها در قالب روشهایی گسترش یافتند که این روشها، ارزشهای بیشتری را به مشتری تحویل می دهند. در مرکز این قانونها، ایده خود سازماندهی     \lr{(self-organizing)}      است. این ایده، اعضای این قانون‌ها را سازماندهی می‌کند. این اعضا مرتب شده نیستند ولی هماهنگ با هم کار می‌کنند و این هماهنگی باعث تقویت همکاری و سودمندی آنها می‌شود. این قانون‌ها، باعث می‌شوند که روش‌ها، تغییرات نیازمندی‌ها را  در هر مرحله هماهنگ نمایند. (روش‌ها با استفاده از این قانون‌ها این کارها را انجام می‌دهند). علاوه بر این، مشتری‌ها بصورت فعال در توسعه نرم‌افزار، بازخورد آسان و بازتاب درگیر می‌شوند و این موضوع منجر به تولید خروجی‌های قابل قبول‌تر می شود، این قانون‌ها تعریف رسمی از چابکی   \lr{(agility)}     نیستند ولی تقریباً رهنمودهایی برای تحویل نرم‌افزار با کیفیت بالا در روش‌هایی بر اساس چابکی هستند. از زمانی که اصطلاح چابکی مطرح شد، محققان سعی کردند که چابکی و شکل‌های محتلف آن را بیشتر تشریح کنند. چابکی در مرکز خودش این قابلیت را دارد که بصورت سریع و منعطف ، تغییرات را ایجاد و به آنها پاسخ بدهد و جنبه‌های دیگر از چابکی کشف شده، شامل سبکی    \lr{(lightness)}          و لاغری         \lr{(leauness)}      و جنبه‌های وابسته مانند چابکی  \lr{(nimbleness)}    ، سرعت        \lr{(quickness)}     ، زبردستی       \lr{(derterity)}         ، فرعی     \lr{(supptenss)}    یا هوشیاری    \lr{(dterness)}     است. این ایده‌ها ، ذاتاً به یک متدولوژی سبک      \lr{(ligth)}   اشاره می‌کند که سرعت پاسخ را افزایش 
می‌دهد. برای      \lr{Henderson seller and serour}    چابکی، هم شامبل قابلیت پذیرش تغییرات است و هم شامل سازگاری و فرآیند توسعه برحسب نیاز می‌باشد .       \lr{lee}    و         \lr{xia}       ، مفهوم چابکی توسعه نرم‌افزار را بصورت زیر تعریف می‌کند: چابکی به این منظور است که تیم نرم‌افزاری بصورت کارا و موثر به تغییرات نیازهای کاربران پاسخ دهد و این نیازها را در مدت چرخه حیات پروژه تطبیق دهد.     \lr{Conboy}         ، با آزمایش کردن سطوح مختلف چابکی و تعریف قانون‌های وابسته، یک تعریف خیلی وسیعی از چابکی توسعه نرم‌افزار را ارایه می‌دهد او میان چابکی و انعطاف‌پذیری و لاغری   \lr{(leaness)}        تفاوت قائل می‌شود. در حقیقت آنطور که تصور می‌شود چابکی، شامل     \lr{leaness}     و        \lr{flexibility}       می‌باشد. انعطاف‌پذیری به توانایی یک متد توسعه برای ایجاد یا پذیرفتن تغییرات بصورت پیشگیرانه، انفعالی و ذاتی در یک زمان مقرر در سراسر مؤلفه‌های داخلی و نیز رابطه‌ی این مؤلفه‌ها با محیط، اشاره می‌کند.  لاغری یک همکاری برای دریافت ارزش‌های مشتری بصورت کاملاً  اقتصادی، با کیفیت و ساده اشاره دارد. بنابراین       \lr{Conboy}        ، چابکی توسعه نرم‌افزار را به عنوان آمادگی پیوسته برای ایجاد ذاتی و سریع تغییرات بصورت پیش‌گسترانه یا انفعالی تعریف می‌کند و تا موقعی که همکاری برای دریافت ارزش‌های مشتری وجود داشته باشد، تغییرات را در سراسر مؤلفه‌های گروهی آن و ارتباط‌های مؤلفه‌ها با محیط آن را دریافت می‌کند. لاغری برای کاهش هزینه از طریق رفع کردن زائده‌ها و عوامل ناکارمد تائید می‌کند و چابکی را از لاغری به عنوان یک توصیف برای تمرکز روی ایجاد پاسخ‌های کارا و نتایج ارزشمند ، استفاده می‌کند. ممکن است لاغری به عنوان یک عامل کفایت‌گرا          \lr{(efficiency-oriented)}      به نظر بیاید. چابکی شامل پذیرش فعالیت‌های لاغر       \lr{(lean)}          با تأکید کردن بر تحقق یافتن خروجی‌های مؤثر می‌باشد.      \lr{Lyytines}        و      \lr{Rose}      اشاره می‌کنند که چابکی که در سراسر پردازش‌های یادگیری دستیابی می‌شود و شامل اکتشاف و بهره‌برداری است. 
\subsection{بررسی تحقیقات انجام شده روی توسعه چابک نرم‌افزار}
یک جستجوی مطبوعاتی، تحقیقاتی که درباره توسعه چابک نرم‌افزار در سال‌های 2001 تا 2010 منتشر شده را شناسایی کرده است. همانطور که در شکل 1 نشان داده شده، تعداد مقاله‌های ژورنال مانند مقاله‌های کنفرانس‌ها ‌تا سال 2010 بصورت یکنواخت رشد داشته است. یک دلیل باورنکردنی برای کاهش تعداد انتشارات کنفرانس‌ها در سال 2010 این است که کنفرانس‌های چابک 2010 در پایگاه‌های دانش  \lr{ISI}       فهرست نشد! افزایش در تحقیقات ژورنال‌ها به این اشاره دارد که میدان تحقیقات کامل شده است. یک بازدید قاعده‌دار از تحقیقات تجربی که قبل از سال 2005 منتشر شد، کمبود دقت تئوری و روش‌شناختی را آشکار کرد. تعداد کلی انتشارات نشان می‌دهد که توسعه چابک باعث 
بهره‌مندی بیشتری در بین اجتماع آکادمیک می‌شود هر چند که بیشتر تحقیقات با توجه به روش‌هایی که از صنعت بیرون می‌آید، ایجاد می‌شود. تحقیقات مطبوعاتی‌ها به ما اجازه می‌دهد،  که وسعت    \lr{agile}     را در کشورهای مختلف بررسی کنیم شکل 2، تعداد نشریه‌ها را بر حسب کشور نشان می‌دهد. رنگ تیره مقدار بیشتری از مقاله‌ها را نشان می‌دهد. علیرغم اینکه وسعت تحقیقات مربوط به   \lr{us}    کانادا و اروپای شرقی بیشتر است، توسعه چابک نرم‌افزار یک زمینه تحقیقاتی در 63 کشور می‌باشد. از شکل 3 در می‌یابیم که کنفرانس‌های بین‌المللی در رابطه با توسعه چابک نرم‌افزار، در اروپا مستقر هستند و بر پایه‌ی چابکی در       \lr{us}    می‌باشند. دو تمرکز کنفرانسی روی موضوع توسعه چابک نرم‌افزار، شگفت‌انگیز نیست راه‌های دیگری برای توسعه چابک نرم‌افزار     \lr{profes}  ،    \lr{EurospI}     (که هر دو بر بهبود فرآیند تمرکز دارند) و کنفرانس بین‌المللی روی مهندسی نرم‌افزار        \lr{(ICSE)}       می‌باشند.       \lr{Euro Micro}       و کنفرانس‌ها روی دانش مهندسی نرم‌افزار و    \lr{Tranning}     نیز می‌توانند مقاله‌های جالبی را در زمینه         \lr{agile}      به سمت خود جذب نمایند. نهایتاً اجتماع    \lr{IFIP}      و کنفرانس بین‌المللی مهندسی نرم‌افزار جهانی  \lr{(ICG SE)}              توانست به خوبی     \lr{ESAM}       برخی توجهات را به این موضوع جلب نماید. بنابراین چندین اجتماع تحقیقاتی روی توسعه نرم‌افزار تمرکز کردند. تعداد زیادی از مقاله‌ها از 10 کنفرانس بالائی می‌باشند. مقاله‌های باقی مانده در مورد 200 زمینه دیگر منتشر می‌شوند. این نشان 
می‌دهدکه توسعه چابک توجهات گسترده‌ای از میان اجتماعات علیم مختلف را به خود جلب نموده است. 
یک نگاه کلی روی انتشارات ژورنال نشان می‌دهد که مجتمع نرم‌افزاری     \lr{IEEE}      بیشترین آمار مقاله‌ها را دارد که تحت این عناوین دنبال شده‌اند: تکنولوژی نرم‌افزار و اطلاعات، ژورنال‌های سیستم و نرم‌افزار و مهندسی تجربی نرم‌افزار. ژورنال اروپایی سیستم‌های اطلاعاتی، یک منتشرکننده برجسته مقاله‌های چابکی در میان ژورنال‌های مهندسی غیر نرم‌افزاری است و به خاطر نتیجه مخصوص روی این موضوع، تشکر می‌کند. تاکنون خروجی‌های مشهور دیگر،      \lr{ACM}      ،‌5 مقاله در مورد توسعه چابک نرم‌افزار، منتشر کرده‌اند. 
\subsection{شرکت‌کننده‌های اصلی و رابطه آنها}
ممکن است برای فهم و درک یک زمینه،‌راه بهتری جز مشخص کردن منابع ابتدائی اطلاعات و رابطه بین آنها، وجود نداشته باشد متخصصان، استفاده از تحلیل‌های(تقدیر کننده از شرکت)     \lr{co-citation}       را برای مشخص کردن زیر بندهای مفهومی از قانون‌ها را به خوبی شرح داده‌اند. مخصوصاً محققان ،  هم نویسندگان و هم اسناد را به عنوان بخش‌هایی از تحلیل به کار برده‌اند. موضوع هر چه که باشد، واحدهای تحلیل به عنوان مفهوم‌هایی که اعلام می‌شوند، در نظر گرفته می‌شوند. تحلیل‌های \lr{co-citation}  می‌توانند بر پایه \lr{co-citation}  روی نویسندگان یا اسناد باشد.  این طرح آزمایشی، تحلیل \lr{co-citation}  بر پایه نویسنده را برای باز کردن موضوعات مفهومی غالب در ادبیات چابکی، استفاده می‌کند. اولین قدم، مشخص کردن نویسندگانی است که بارهای بیشتری در ادبیات چابکی ذکر شده‌ند.   \lr{ISI}      برای این هدف استفاده نشد. تحقیق ما، 452 مقاله را واگذار می‌کند. ارجاعات ذکر شده و از هر یک از این مقاله‌ها، برای مشخص کردن لیست بیشترین نویسندگان ، استفاده شده‌اند. 
در تحلیل نهایی ما، 51 نویسنده قرار گرفته‌اند. یک ماتریس 51×51 بر مبنای تحقیق ارجاعات ذکر شده شکل گرفت که سطرهای آن تعداد \lr{co-citation}  را نشان می‌دهد و شامل 51 نویسنده است. تعداد \lr{co-citation}  از یک زوج از نویسندگان با مشخص کردن تعداد رکوردهای تطبیقی در ارجاعات مربوط به آن‌ها، مشخص شد. ورودی برنامه تحلیل گروهی، یک ماتریس همبستگی بود که از ماتریس  51×51 مشتق شده بود. ما از متد کلمات      \lr{(Words)}  را استفاده کردیم. نتیجه در شکل 5 نشان داده شده است. فاصله‌های موجود در شکل، سطح تشابه مفهومی بین دو نویسنده را نشان می‌دهد که فاصله کوتاه‌تر به نزدیکی موضوعی بیشتر در نوشته‌های دو نویسنده اشاره دارد. به عنوان مثال، فاصله پیوسته و کوتاه بین    \lr{Fowler}        و    \lr{Gammq}      (که هر دو درباره الگوها موضوعاتی را نوشته‌اند)، نشان می‌دهد که کارهای آنها خیلی به هم نزدیک است. تحقیقات زیادی در رابطه با اختلاف موجود میان روش‌های فرآیندگرا (که با عنوان    \lr{CMM/CMMI}        وجود دارند) و متدهای چابکی نظیر    \lr{XP}   ، وجود دارند. علاوه بر این مناظرات گسترده‌ای روی موضوعاتی از قبیل تطبیق دادن تفاوت‌های میان چابکی و روش‌های قبلی، ایجاد یک تعادل بین روش‌های سنتی و چابکی، استفاده از یک روش ریسک‌محور    \lr{(risk-driven)}        برای انتخاب تغییرات و   \lr{forth}      وجود دارد. وجود برنامه‌نویسی زوجی و توسعه بر مبنای آزمایش  \lr{(test-driven)}     موضوع عجیبی نیست زیرا     \lr{sharp}     و    \lr{Robinson}     تعداد زیادی از مقالات جالب خود را به خاطر کار روی موضوع  \lr{XP}      مخصوصاً در مفهوم‌های فرهنگ سازمانی، شناخت توزیع شده و نقش محصولات فیزیکی در توسعه چابک، از دیگران جدا کردند. تأثیر الگوهایی که بر پایه کارهای   \lr{Fowler}    Fowler و   \lr{Gammq}       Gammq هستند(هم الگوهای تحلیل و هم الگوهای طراحی)، در طراحی‌ها کاملاً مشهود است. کتاب    \lr{IEEE}    Robert Martin که در مورد توسعه چابک نرم‌افزار است، نقش الگوها را در توسعه چابک نشان می‌دهد. از این رو میان     \lr{Fowler}          و \lr{Robert Martin}    و    \lr{Gammq}       ارتباط ایجاد می‌کنیم بخش بعدی چشم‌اندازهای تئوری مختلفی که در تحقیقات قبلی استفاده شده‌اند را نشان می‌دهد. 
\subsection{شناسایی تئوری توسعه چابکی}
توسعه چابک به واسطه آزمایشات شخصی و دانش گروهی مشاوران و اندیشه‌های رؤسای اجتماع نرم‌افزار، حاصل شد. زمانیکه روش‌های چابکی در حال درک و شکل‌گیری اولیه بود، آنها زیربندهای تئوری و حمایت تجربی از مزایای خود را کم داشتند. بنابراین یک نیاز مبرم به جنبه‌های تئوری وجود داشت که این جنبه‌ها می‌توانست راهنمایی‌هایی در مورد رفع تجانس میان روش‌ها بدهد و نیز باعث شود که برهم کنشها، خروجی‌های با ارزشی ارایه دهند. یکی دیگر از اهمیت‌های تحقیق، دریافت تفاوت میان متدهای اجایل و نظیر سنتی آن‌ها به صورت تئوری بود. برای مثال   \lr{Nerur}    و    \lr{Balijepally}  با مثال توضیح داده‌اند که تغییر در روش‌های توسعه 
نرم‌افزار که در متدهای Agile آشکار  است، با تغییر های مشابه در طراحی ، برابری می‌کند و این موضوع در چندین حوزه نابرابر آشکار است مانند دامنه‌های مدیریت استراتژیک و معماری. برای داشتن درکی از جنبه‌های مختلف تئوری استفاده شده در مطالعات روی توسعه اجایل که در دهه گذشته انجام شده‌اند،‌یک تحلیل سریع رو ی452 مقاله‌ای که پس از تحلیل \lr{co-citation} از نویسندگان، تعیین شدند انجام می‌دهیم. آمار 245 مقاله موجود   \lr{ISI}  در جدول 1 آمده است. یک روش برای ایجاد ارتباط بین مقاله‌ها ، توجه به کلمات کلیدی موجود در آن‌هاست که این روش در اینجا استفاده شده است. هر چند که ما باور داریم که این موضوع ، یک درک کلی از جنبه‌های تئوری مختلف که در مطالعات   \lr{agile}   و وابستگی آن‌ها را به ما نشان می‌دهد. همانطور که از جدول 1 مشهود است، مدیریت دانش، شخصیت، آموزش سازمانی و جنبه‌های وابسته نزد محققان چابکی، محبوب‌ترند. چون توسعه نرم‌افزار یک فعالیت مربوط به ایجاد دانش است، در زمان تولید دانش در تیم نرم‌افزاری در حالت کلی و تیم چابکی در حالت اختصاصی، مدیریت دانش یک جنبه جذاب می‌باشد. بصورت مشابه، تئوری‌های شخصی، باید در اکتشاف پویایی میان فردی تیم‌های اجایل گروهی شده و زوج‌های برنامه‌نویسی، مفید باشد. انتظار می‌رود که قانون‌های چابکی مربوط به آمادگی و سازگاری تغییرات ، یک محیط یادگیری را در تیم چابک ایجاد کنند. بنابراین یادگیری سازمانی و جنبه‌های مربوطه، زمان اکتشاف خروجی‌های یادگیری ، خواستار یک انتخاب منطقی برای محققان هستند. همانگونه که در جدول 1 نشان داده می‌شود، جنبه‌های دیگر تئوری، برای یک توسعه کوچکتر استفاده می‌شوند. به نظر نمی‌آید که مطالعات اجایل به زیربندهای تئوری علاقه‌مند باشند بنابراین بصورت عمومی درک شده که تحقیقات   \lr{agile}    بصورت  \lr{a-theoretical}     می‌باشند. 
\section{یک تئوری از توسعه چابک نرم‌افزار}
در این بخش ما ابتدا جدیدترین تکنولوژی در توسعه چابک را معرفی می‌کنیم. سپس در بخش‌های بعدی این مفهوم خاص را در زمینه کاری به کار می‌بریم. 
\subsection{یک دید روی تحقیقات قبلی}
معرفی و دید روی توسعه نرم‌افزار، با     \lr{ahansson}    و همکارانش ،   \lr{cohen}      و همکارانش،   \lr{Erickson}    و همکارانش و     \lr{Dyba} و   \lr{DingSoys}      ارائه شده است. این چهار گزارش جدیدترین تکنولوژی و جدیدترین روش را بر حسب خصوصیات متدهای قبلی \lr{agile} و درس‌هایی که از پیاده‌سازی اینگونه متدها در صنعت یادگرفته شده، شرح می‌دهد. علاوه بر این، کتاب       \lr{Agile Software Current Research and Future Direction}    شامل 11 دید از جریان‌های اصلی تحقیق \lr{agile}  است و در چند فصل ساختار بندی شده است و این فصل‌ها، اساس و پس زمینه توسعه نرم‌افزار، متدهای \lr{agile} در عمل، چالش‌های عمده و مرزهای جدید را شرح می‌دهند. از سال 2003 تا 2011، پنج موضوع مخصوص و یک بخش ویژه در رابطه با توسعه چابک نرم‌افزار در 32 مقاله منتشر شده‌اند. بیشتر متدهای توصیف شده‌ی     \lr{agile}    \lr{XP}،  و       \lr{scrum}    بودند. یک بررسی مشخص کرد که بیشتر مقاله‌ها، علاقه‌مندند تا درک مفهوم \lr{agile} را برای ما پیش ببرند. موضوعات غالب دیگر شامل پذیرش چابکی، اصلاح تنش‌ها میان چابکی و توسعه بر مبنای طرح  \lr{(plan-driven)}     و ارزشیابی نتیجه پذیرش چابکی در محیطی که ذاتاً سودمند نیست، می‌باشند. در سال 2003،      \lr{Cockburn}      و    \lr{willioms}     ، یک برآورد مخصوص را تحت لقب       \lr{Computer}      ویرایش کردند: 
"توسعه چابک نرم‌افزار: آن درباره بازخورد و تغییر است "   
تأکید اصلی این برآورد بر تعیین چگونگی ترکیب متدولوژی‌های \lr{agile} با روش‌های مبنی بر طرح در توسعه نرم‌افزار می باشد. ششمین مقاله شامل تاریخچه توسعه تکرار و افزایش است و این که این دو روش چه موقع و چگونه ترکیب می‌شوند. علاوه بر این ، این نتایج، تجربه استفاده از       \lr{XP}          و      \lr{scrum}     را به خوبی معرفی پردازش چابکی در کار سازمانی ، گزارش کردند. دومین نتیجه در ژورنال مدیریت پایگاه داده در سال 2005، به نظر آمد. برای داشتن یک بازدید از حالت تحقیق روی    \lr{XP}    و متدهای \lr{agile} نتایج، موضوعات وابسته به پذیرش متدهای چابک، اصلاح فرآیند،     \lr{XP}    و فرضیات اساسی چابکی را در بر گرفت. 
در سال 2009،         \lr{Abrahamsson}     و همکارانش، برای دریافت یک نتیجه درباره ژورنال‌های اروپایی سیستم‌های اطلاعاتی، هفت مقاله را به منظور افزایش درک ما از پدیده‌های  مختلف توسعه چابک سیستم، انتخاب کردند. 
هنوز نتایج مخصوص دیگر در آزمایش و روش نرم‌افزار منتشر می‌شوند که توسط    \lr{Hamon}     و    \lr{Hreer}      ویرایش شده است. مقاله‌ها، دسته وسیعی از حوزه‌های تحقیقاتی را آدرس‌دهی می‌کنند. این حوزه‌ها شامل کاربرد متدولوژی‌های چابک برای توسعه بحرانی ایمن نرم‌افزار، رابطه بین توسعه چابک و طراحی تجربی کاربر و اندازه‌گیری جریان در توسعه ضعیف نرم‌افزار است.برای داشتن یک برآورد خاص، ما خواستار یک همکاری شدیم که این همکاری بصورت بحرانی روی حالت جاری تحقیق و تکنیک توسعه نرم‌افزار، بازتاب شود. ما پرسش‌های همکاری را جستجو کردیم و زیربندهای تئوری چابکی و توسعه ضعیف و بیانیه چابک را کشف کردیم. ما به یک کلیت از 21 تابع دست یافتیم که 5 تای این‌ها برای نتیجه خاص انتخاب شدند. سه تا از این مقاله‌ها بر جنبه‌های ویژه از روش‌های چابکی (مانند هماهنگی و تصمیم‌گیری) تمرکز می‌کنند. در حالیکه دو مقاله آخر بینشی را روی موضوعات کلی توسعه نرم‌افزار، یک تئوری اعمال شده از توسعه نرم‌افزار و یک بازنگری از گزارشات آزمایش روی توسعه ضعیف و چابک نرم‌افزار، ارائه می‌دهد. ما این همکاری‌ها را جزئیات بیشتر در زیر شرح داده‌ایم. در مقاله آنها    \lr{strode}   ،  \lr{Huff}     و   \lr{Hope}      ، توسعه چابک را به تئوری خود ارتباط دادند و این کار را با استفاده از یک مدل با این سه مؤلفه انجام دادند: همزمان‌سازی، ساخت و محدودسازی مرز. 
تصمیم‌گیری   \lr{(dicision-making)}     یک جنبه مهم از توسعه نرم‌افزار است که  \lr{agile}     \lr{power}   ، Drury و      \lr{conboy}          در مقاله خود یعنی "موانع تصمیم‌گیری  در تیم‌های توسعه نرم‌افزار" روی این موضوع تمرکز کرده‌اند. آنها با بکارگیری روش‌هایی که متدها را ترکیب می‌کنند، تصمیماتی که در طراحی تکرارها، اجرا، بازنگری به گذشته و مشخص کردن 6 مانع تصمیم‌گیری در گیر بودند را بررسی کردند.    \lr{senapathi}          و   \lr{Srrnivasan}      در مقاله‌شان برای استفاده از روش‌های توسعه چابکی در مرحله گرفتن پست   \lr{(post-adoption)}  ، تمرکز کردند. آن‌ها تئوری خود را وفق دادند و ابداعات خود را منتشر کردند و بدینوسیله ، مدلی را توسعه دادند که مرحله post-adoptionدر روش‌های چابکی را شرح می‌دهد.     \lr{Adolph}    و   \lr{kruchten}  در مقاله    \lr{Reconciling perspective How people manage the process of software development}     یک توسعه از فاکتورهای اجتماعی توسعه نرم‌افزار را گسترش داده‌اند آنها توسعه نرم‌افزار را به عنوان یک پردازش مذاکره‌ای که جنبه‌های وفقی را درگیر می‌کند، در نظر گرفتند و این موضوع یک جنبه واحد ایجاد می‌کند که این جنبه بررسی می‌کند که توسعه چابک نرم‌افزار چگونه در سازمان‌ها مورد قبول واقع می‌شود. در کنفرانس‌های مربوط به چابکی ، روی یک موضوع، تمرکز خاصی می‌شود یعنی راه‌هایی برای ترکیب قانون‌های توسعه لاغر با توسعه نرم‌افزار. 

\chapter{فرآیند توسعه چابک نرم‌افزار چیست؟}
\section{مقدمه}
فرآیند تولید و توسعه نرم‌افزار ، ذاتأ یک فرآیند بی‌نظم است که جهت نظم دادن به این بی نظمی‌ها ، از متدولوژی‌های توسعه نرم‌افزار بهره می گیریم. 
متدولوژی توسعه نرم‌افزار مشخص می‌کند که چه فرآورده‌ای   \lr{(What)}       ، توسط چه کسی    \lr{(Who)}     و در چه زمانی    \lr{(When)}      تولید شود. 
سیر تکاملی متدولوژی‌های توسعه نرم‌افزار در شکل 1 خلاصه شده است. مدل آبشاری \lr{waterfall،}        در مواردی که نیازمندی‌ها ثابت هستند، استفاده می‌شود. در این متدولوژی، هر فاز، زمانی که فاز قبلی تمام شود، شروع می‌شود. این مطلب نمایشگر روش‌های سنتی است. به منظور غلبه بر محدودیت‌های روش آبشاری، مدل تکاملی   \lr{evolutionary}      و مدل حلزونی   \lr{spiral}      ، نمونه اولیه           \lr{prototype}                را بوجود آورند و سپس نرم‌افزار قابل اجرا    \lr{working software}    را از روی آن ایجاد کردند. اما تمام این ‌فرآیندها یک محدودیت را دارند و این محدودیت این است که هیچ یک از مدل ها نمی‌توانند تغییرات در نیازمندی‌ها را در فازهای بعدی، مدیریت نمایند. فرآیند توسعه چابک نرم‌افزار دارای متدهای مختلفی است که به متدهای توسعه سبک       \lr{(light)}     نرم‌افزار معروف هستند و این متدها در اواسط دهد 1990 تکامل یافتند و در واقع به عنوان واکنشی در مقابل ناکامی‌های رو به افزایش متدهای سنگین‌وزن مانند ساختارهای مبتنی بر روش آبشاری و ... هستند و اساس کار خود را بر برنامه و مستندات فراوان قرار می‌دهند، پدیدار گشتند. 
در طراحی یک نرم‌افزار رعایت اصول استاندارد طراحی، استفاده از الگوهای آماده و بهره‌گیری از روش‌های نوین، بسیار مهم است ولی نکته مهم این است که در اصل کاربران، باعث می‌شوند که یک پروژه نرم‌افزاری به نتیجه برسد. یعنی فناوری و پردازش‌های انجام شده، در رده بعدی اهمیت قرار دارند. 
 فرآیندها توسعه چابک نرم‌افزار، شامل متدولوژی‌هایی 
مانند     \lr{ lean software development}       ،          \lr{XP}  و     \lr{Scrum}      توسعه بر مبنای ویژگی       \lr{(FDM)}       و توسعه بر مبنای آزمایش می‌باشد    \lr{(TDD)}   . فرآیندها توسعه چابک نرم‌افزار، به علت پذیرفتن تغییرات حتی در مراحل بعدی و نیز به خاطر سرعت توسعه، مورد قبول صنعت نرم‌افزار قرار گرفت. 
\section{فلسفه توسعه چابک نرم‌افزار}
در وضعیتی که تیم‌های نرم‌افزاری در بسیاری از شرکت‌ها خود را در مردابی از فرآیندهای زیاد شونده می‌دیدند، 17 مخترع و شاغل در زمینه توسعه چابک نرم‌افزار که خود را اتحاد چابک نامیدند در اویل سال ۲۰۰۱ یکدیگر را ملاقات کرده و ارزش‌هایی را معرفی کردند تا تیم‌های نرم‌افزاری سریع‌تر نرم‌افزار را توسعه داده و زودتر به تغییرات پاسخ دهند و چند ماه بعد، این گروه ارزش‌هایی تعریف شده را تحت مانیفست اتحاد چابک در سایت     \lr{http://agilemanifesto.org}    منتشر کردند. بنابراین زمینه‌ای برای توسعه چابک نرم‌افزار ایجاد شد. این شرکت‌کنندگان ، مفهوم توسعه چابک نرم‌افزار را بصورت زیر بیان می‌کند: ما راه‌های بهتری از توسعه نرم‌افزار را از طریق انجام دادن آن و نیز کمک به دیگران برای انجام آن، کشف می‌کنیم . 
\section{ارزش‌هایی که فرآیند توسعه چابک به آن‌ها دست می‌یابد }
\begin{itemize}
\item  \textbf{افراد و تعاملات بالاتر از فرآیندها و ابزارها } 

افراد مهم‌ترین نقش را در پیروزی یک پروژه دارند. یک فرآیند عالی بدون نیروی مناسب منجر به شکست می‌گردد و بر عکس افراد قوی تحت فرآیند ضعیت ناکارآمد خواهند بود. یک نیروی قوی لازم نیست که برنامه‌نویسی عالی باشد، بلکه کافیست که یک برنامه‌نویسی معمولی با قابلیت همکاری مناسب با سایر اعضای تیم باشد. کار کردن با دیگران، تعامل درست و سازنده با سایر اعضای تیم خیلی مهمتر از این که یک برنامه‌نویس باهوش باشد. برنامه‌نویسان معمولی که تعامل درستی با یکدیگر دارند به مراتب موفق‌تر هستند از تعداد برنامه‌نویسی عالی که قدرت تعامل مناسب با یکدیگر را ندارند. 
\item    \textbf{نرم‌افزار کاری       \LTRfootnote{working software}  بالاتر از  مستندات جامع} 

نرم‌افزار     بدون مستندات، فاجعه است. کد برنامه ابزار مناسبی برای تشریح سیستم نرم‌افزاری نیست. تیم باید مستندات قابل فهم مشتری بسازد تا ابعاد سیستم از تجزیه تحلیل تا طراحی و پیاده‌سازی آن را تشریح نماید. 
با این حال، مستندات زیاد از مستندات کم، بدتر است. ساخت مستندات زیاد نیاز به وقت زیادی دارد و وقت بیشتری را می­گیرد تا آن را با کد برنامه به روز نمایید. اگر آنها با یکدیگر به روز نباشند باعث درک اشتباه از سیستم می­شوند. بهتر است که همیشه مستندات کم‌حجمی از منطق و ساختار برنامه داشته  باشید و آن را به روز نمایید. البته آنها باید کوتاه و برجسته باشند. کوتاه به این معنی که ۱۰ تا ۲۰ صفحه بیشتر نباشد و برجسته به این معنی که طراحی کلی و ساختار سطح بالای سیستم را بیان نماید. 
\item    \textbf{مشارکت مشتری بالاتر از قرارداد کاری} 

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

توانایی پاسخ به تغییرات اغلب تعیین‌کننده موفقیت یا شکست یک پروژه نرم‌افزاری است. وقتی که طرحی را می‌ریزیم باید مطمئن شویم که به اندازه کافی انعطاف‌پذیر است و آمادگی پذیرش تغییرات در سطح بیزنس و تکنولوژی را دارد. مسیر یک پروژه نرم‌افزاری نمی‌تواند برای بازه زمانی طولانی برنامه‌ریزی شود. اولاً احتمالاً محیط تغییر می‌کند و باعث تغییر در نیازمندی‌ها  می‌شود. ثانیاً همین که سیستم شروع به کار کند مشتریان
 نیازمندی‌های خود را تغییر 
می‌دهند. بنابراین اگر بدانیم که نیازها چیست و مطمئن شویم که تغییر نمی‌کنند، قادر به برآورد مناسب خواهیم بود، که این شرایط بعید است. 
\end{itemize}
\section{اصول چابک چیست؟ }
\begin{enumerate}
\item      \textbf{بالاترین اولویت ما عبارت است از راضی کردن مشتری با تحویل سریع و مداوم نرم‌افزار با­ارزش: }تحویل
 نرم‌افزار با کارکردهای کم در زود هنگام بسیار مهم است چون هم مشتری چشم‌اندازی از محصول نهایی خواهد داشت و هم مسیر کمتر به بیراهه می‌رود. 
\item    \textbf{خوش‌آمدگویی به تغییرات حتی در انتهای توسعه. } 
اعضای تیم چابک، تغییرات را چیز خوبی می‌بینند زیرا تغییرات به این معنی است که تیم بیش‌تر یاد گرفته است که چه چیزی مشتری را راضی می‌کند. 
\item    \textbf{تحویل نرم‌افزار قابل استفاده از چند هفته تا چند ماه با تقدم بر تحویل در دوره زمانی کوتاه‌تر} 
ما مجموعه از مستندات و طرحها را به مشتری نمی­دهیم. 
\item    \textbf{افراد مسلط به بیزنس و توسعه‌دهندگان باید روزانه با یکدیگر روی پروژه کار کنند. } 
یک پروژه نرم‌افزاری نیاز به هدایت مداوم دارد. 
\item    \textbf{ساخت پروژه را بر توان افراد با انگیزه بگذارید و به آنها محیط و ابزار را داده و اعتماد کنید.  } 
مهم‌ترین فاکتور موفقیت افراد هستند، هر چیز دیگر مانند فرآیند، محیط و مدیریت  فاکتورهای بعدی محسوب
 می‌شوند که اگر تأثیر بدی روی افراد می‌گذارند، باید تغییر کنند. 
\item    \textbf{بهترین و مؤثر ترین روش کسب اطلاعات در تیم توسعه، ارتباط چهره به چهره است. } 
در تیم چابک افراد با یکدیگر صحبت می‌کنند. نامه‌نگاری و مستند سازی فقط زمانی که نیاز است باید صورت گیرد. 
\item    \textbf{نرم‌افزار کار کننده معیار اصلی پیشرفت است.} 
پروژه‌های چابک با نرم‌افزاری که در حال حاضر نیازهای مشتری را پاسخ می‌دهد، سنجیده می‌شوند. میزان مستندات، حجم کدهای زیر ساخت و هر چیز دیگری غیر از 
نرم‌افزار کار کننده معیار پیشرفت نرم‌افزار نیستند. 
\item    \textbf{فرآیندهای چابک توسعه با آهنگ ثابت را ترویج می‌دهد.} 
حامیان، توسعه‌دهندگان و کاربران باید یک آهنگ توسعه ثابت را حفظ کنند. آنها با سرعتی کار می‌کنند که بالاترین کیفیت را ارائه دهند.
\item    \textbf{توجه مداوم به برتری تکنیکی و طراحی خوب منجر به چابکی می‌گردد.} 
کیفیت بالاتر کلیدی برای سرعت بالا است. راه سریع‌تر رفتن این است که نرم‌افزار تا جایی که ممکن است پاک و قوی نگه داریم. بنابراین همه اعضای تیم چابک تلاش می­کنند که با کیفیت‌ترین کار ممکن را انجام دهند. آنها هر آشفتگی را به محض ایجاد برطرف می‌کنند. 
\item    \textbf{سادگی هنر بیشینه کردن مقدار کاری که لازم نیست انجام شود، است. } 
تیم چابک همیشه ساده‌ترین مسیر که با هدف آنها سازگار است را در پیش می‌گیرند. آنها وقت زیادی روی مشکلاتی که ممکن است فردا رخ دهد، نمی‌گذارند.  آنها کار امروز را با کیفیت انجام داده و مطمئن می‌شوند که تغییر آن در صورت بروز مشکلات در فردا، آسان خواهد بود. 
\item    \textbf{بهترین معماری و طراحی از تیم‌های خود­سازماندهی شده بیرون می‌آید.} 
مدیران، مسئولیت‌ها را به یک فردی  خاصی در تیم نمی‌دهند بلکه بر عکس با تیم به صورت یک نیروی واحد برخورد می‌کنند. خود تیم تصمیم می‌گیرد که هر مسئولیت را چه کسی انجام دهد. تیم چابک با هم روی کل جنبه‌های پروژه کار می‌کنند. یعنی یک فرد خاص مسئول معماری، برنامه‌نویسی، تست و غیره نیستند. تیم، مسئولیت‌ها را به اشتراک گذاشته و هر فرد بر کل کار تأثیر دارد. 
\item    \textbf{در بازه‌های زمانی مناسب تیم در می‌یابد که چگونه می‌تواند کاراتر باشد و رفتار خود را متناسب با آن تغییر دهد.} 
تیم می‌داند که محیط دائماً در حال تغییر است، بنابراین خود را با محیط تغییر می‌دهد تا چابک بماند.
\end{enumerate}
\section{توسعه چابک چیست؟ }
توسعه چابک نگرشی برای تولید نرم‌افزار است که در آن نرم‌افزار (محصول) به صورت مرحله به مرحله و تکاملی تحویل مشتری می‌گردد و با ارتباط تنگاتنگ با او سعی می‌شود که رضایتش جلب شود. تیم تولید با بهره‌گیری از بهترین روش‌ها و ابزارها تلاش می‌کند تا کیفیت نرم‌افزار را در سطح بالایی نگه دارد و البته زمان‌بندی تعیین شده را رعایت نماید. تیم‌های توسعه چابک خود­سازمانده    \LTRfootnote{self-organizationt}     و میان‌کارکردی هستند و بر اساس 
برنامه‌ریزی تطبیقی، انعطاف‌پذیری نسبت به تغییرات و  تحویل به موقع عمل می‌کنند.“ مدل چابک از بازخوردها به جای برنامه‌ریزی بعنوان مکانیزم اصلی کنترل پروژه استفاده می‌کند.بازخوردها بوسیله تست و آزمون‌های مرتب و انتشار پیاپی و در بازه‌های کوتاه زمانی نرم‌افزارهای در حال تکامل تولید می‌شوند. متدهای چابک از کل پروژه و درنظرگیری تمامی جزئیات آن در ابتدای کار، اجتناب نموده و پروژه را به بخش‌های کوچک تقسیم می‌کنند و سپس با برنامه‌ریزی هر بخش و تکمیل آن و افزودن آن به سایر بخش‌ها، پروژه را پیش می‌برند. این بخش‌ها غالباً در بازه‌های زمانی کوتاه‌مدت که معمولاً بین یک تا چهار هفته است، توسعه می‌یابند. هر بازه زمانی یک چرخه توسعه نرم‌افزار کامل است که شامل برنامه‌ریزی، آنالیز نیازمندی‌ها، طراحی، برنامه‌نویسی، تست واحد   \LTRfootnote{unit test}   و تست پذیرش   \LTRfootnote{Acceptance test}   است. این شیوه، ریسک کلی پروژه را کاهش می‌دهد و امکان تطابق با تغییرات را نیز به سرعت فراهم می‌کند. هدف آن است که در انتهای هر بازه زمانی، بخش قابل ارائه‌ای از نرم‌افزار با حداقل میزان اشکالات تولید شود اما این بخش لزوماً شامل عملکردهای کافی نیست و ممکن است برای ارائه یک محصول و حتی یک مشخصه جدید، چندین بازه زمانی لازم باشد. کارهایی که در هر بازه زمانی با حضور نماینده مشتری یا مشتریان و توسعه‌دهندگان سیستم، برگزار می‌شوند. اما نکته‌ی مهم این است با توجه به وجود بازه‌های زمانی کوتاه‌مدت در روش‌های چابک، ما با توسعه مبتنی بر تکرار مواجه هستیم. در توسعه مبتنی بر تکرار، نگارش‌هایی از سیستم نهایی تولید می‌شود که دربرگیرنده جنبه‌های مورد نیاز سیستم است. این نگارش‌ها می‌توانند عملیات کوچک و مطمئنی را انجام دهند. توسعه مبتنی بر تکرار در فرآیندهای تطبیقی ضروری است. زیرا این‌گونه فرآیندها باید با تغییرات ایجاد شده در جنبه‌های مورد نیاز سیستم تطبیق پیدا کنند و چنین چیزی با طرح‌ریزی بلندمدت برای سیستم سازگار نمی‌باشد. بنابراین در یک فرآیند تطبیقی، طرح‌هایی کوتاه‌مدت برای یک بازه زمانی کوتاه‌مدت ایجاد می‌شود. 
\newpage
تطبیق دو جنبه دارد: 
\begin{enumerate}
\item  تغییر در نرم‌افزار برای تطبیق با تغییرات ایجاد شده در نیازمندی‌های مشتری 
\item                تغییر در فرآیند تولید: بدین مفهوم که روند تولید در پایان هر بازه زمانی، مواردی مانند بازدید، نقاط ضعف و قوت، بررسی شده و تصمیماتی برای بازه زمانی بعدی اتخاذ می‌شود. 
\end{enumerate}

\chapter{توسعه چابک و توزیع شده نرم‌افزار }
\section{مقدمه}
در دهه گذشته سرمایه‌گذاری های زیادی برای تبدیل مراکز تجاری     ملی به مراکز تجاری جهانی صورت گرفته است. همچنین چالش‌های متفاوتی مانند نقص‌های پروژه و کمیابی منابع        در توسعه نرم‌افزار، دیده می‌شوند. و این مربوط به زمانی است که فرآیند توسعه نرم‌افزار توسط افرادی که در یک مکان    \LTRfootnote{co-located}          قرار دارند، انجام شود. بنابراین بسیاری از سازمان‌ها برای حل این مشکلات، اقدام به استفاده از فرآیند توسعه توزیع شده نرم‌افزار                 \LTRfootnote{Distributed software Development}     نمودند که به اختصار به آن     \lr{DSD}                                  می‌گویند. توسعه توزیع شده نرم‌افزار به این معنی است که افراد اعضای تیم، الزاماً نباید در یک مکان حضور داشته باشند یعنی می‌توانند در مکان‌های مختلف حضور داشته باشند. استفاده از فرآیند توسعه توزیع شده نرم‌افزار باعث دستیابی به منابع تخصصی بیشتر می‌شود، بنابراین هزینه  تولید کاهش یافته و کیفیت                   محصول نسبت به زمانی که توسعه نرم‌افزار در یک مکان است،  بهتر می‌شود. در توسعه جهانی نرم‌افزار \LTRfootnote{Global Software Development}                    که به اختصار به آن                  \lr{GSD}          نیز 
می‌گویند ، یک تیم نرم‌افزاری راه حل‌های موردنیاز خود را در کشورهای دیگر جستجو می‌کند و نرم‌افزار در محیطی که شامل چند مکان                   \LTRfootnote{Multi-site}  ، چند فرهنگ                        \LTRfootnote{Multi-cultural}و در سراسر جهان گسترش می‌یابد.  در فرآیند توسعه توزیع شده نرم‌افزار، خطر ناشی از بلاهای ناگهانی             ملی کاهش می‌یابد و نیز مخزنی           \LTRfootnote{repository}  از منابع تخصصی جهانی ایجاد می‌شود. برخی از سازمان‌ها، توسعه نرم‌افزار را بصورت جهان‌گستر انجام می‌دهند و این کار را به منظور دستیابی به سود      ، بهره‌وری              کیفیت بیشتر و هزینه کمتر انجام می‌دهند. این عوامل نه تنها بر مراکز تجاری تأثیر عمیق دارند، بلکه بر فهم، طراحی، ایجاد ، تست و تحویل محصول به مشتری نیز تأثیر عمیق دارند. 
\newpage
\section{عواملی که توزیع طبق آن‌ها می‌باشد}
در حالت کلی، توزیع می‌تواند با توجه به عوامل زیر انجام شود: 
\subsection{ ساختار کنترل}
ساختار کنترل دارای دو بعد است:
\begin{itemize}


\item    منبع‌یابی از خارج  سازمان \LTRfootnote{Outsourcing} :   منبع‌یابی از خارج  سازمان به این معنی است که شرکت، محصولات خود را از شرکت‌های دیگر می‌خرد. 
\item     منبع‌یابی از داخل  سازمان    \LTRfootnote{Insourcing}:    منبع‌یابی از داخل  سازمان به این معنی است که شرکت، سرویس‌های موردنیازش را از طریق پروژه‌های داخلی فراهم می‌کند. 
\end{itemize}
%\begin{itemize}
%\item
%\item[$\star$]
%\item[$\ast$]
%\item[$\dagger$]
%\item[$\ddagger$]
%\item[$\diamond$]
%\end{itemize}


\subsection{مکان جغرافیایی }
مکان جغرافیایی  دارای دو بعد است: 
\begin{itemize}


\item    داخل شرکت     \LTRfootnote{onshore}    : به این معناست که تمام کارهای مربوط به توسعه در همان شرکت رخ 
می‌دهد یعنی در مکانی که شعبه مرکزی و اعمال دیگر قرار  دارند. به این حالت فرآیند توسعه توزیع شده نرم‌افزار نیز گفته می‌شود. 
\item  خارج شرکت         \LTRfootnote{offshore}     : به این معنی است که قسمتی از عملیات توسعه خارج از کشور رخ 
می‌دهد. که به این حالت توسعه جهانی نرم‌افزار نیز گفته می‌شود. 
\end{itemize}
\section{برخی از ویژگی‌های توسعه جهانی نرم‌افزار }
1)    برخی از ویژگی‌های توسعه جهانی نرم‌افزار عبارتند از: 
\begin{itemize}
\item        فاصله  \lr{(Distance)}   : بیانگر فاصله میان توسعه‌دهندگان از هم و از مشتریان و کاربران نهایی است. 
\item           تفاوت ناحیه‌های زمانی     \lr{(Time-zone)}   : برای یک گستره بزرگ، ناحیه زمانی بر خلاف فاصله، عاملی گیج‌کننده می‌باشد 
\item فرهنگ ملی    \lr{(culture National)}     : شامل زبان، سنت‌های ملی و قوانین رفتاری است. 
\end{itemize}
\section{مشکلات فرآیند  توسعه توزیع شده}
برخی از مشکلات توسعه توزیع شده جهانی نرم‌افزار عبارتند از: 
\subsection{موارد حاصل از راه‌حل‌ها }
اگر تیم‌های پروژه نرم‌افزاری در مکان‌های مختلف توزیع شده باشند، و یا داخل یک شرکت واحد باشند، در هر صورت تصمیمات باید اتخاذ شود.علاوه بر این باید کارها را بین تیم‌هایی که در مکان‌های مختلف هستند، تقسیم کنیم. این مرحله ریسک‌های زیادی دارد. علاوه بر این راه حل‌های متفاوتی در هر مکان وجود دارند که با توجه به شرایط مختلف باید آن‌ها را انتخاب نمود. 
\subsection{موارد فرهنگی }
زمانی که افرادی بافرهنگ‌های   مختلف در طول یک پروژه با هم همکاری می‌کنند، اثرات تفاوت فرهنگ آن‌ها دیده می‌شود. جنبه‌های مختلف تفاوت فرهنگ عبارتند از: ملیت، تخصص، رفتار، سازمان، فن و فرهنگ تیم. تفاوت‌های فرهنگی ، مشکلات ارتباطی را افزایش می‌دهند. 
\subsection{ارتباطات ناقص }
توسعه نرم‌افزار به ارتباطات رسمی نیاز دارد که این ارتباطات باید از طریق کانال‌های ارتباطی اساسی ، امکانپذیر باشد. ساختار پیچیده توسعه جهانی نرم‌افزار و اندازه بزرگ شبکه‌های کاربران، باعث کاهش ارتباطات و در نتیجه کاهش کیفیت می‌شود که این امر مستقیماً روی بهره‌وری تأثیرگذار است. تفاوت ناحیه‌های زمانی نیز بر ارتباطات تأثیرگذار است. 
\subsection{مدیریت دانش }
روشها، تجربه‌ها، تصمیمات و توانایی‌های اعضای تیم در طول فرآیند توسعه نرم‌افزار، باید متراکم  شود . این متراکم‌سازی از طریق تقسیم اطلاعات امکانپذیر است. افراد، از طریق متراکم‌سازی ارتباطات قادرند تا از تجربیات دیگران استفاده نمایند که این کار باعث کاهش هزینه و نیز کاهش کارهای تکراری  می‌شود. مدیران بدون تقسیم دانش  نمی‌توانند از مزایای توسعه جهانی نرم‌افزار بهره‌مند شوند. برای این منظور مخزنی از دانش را تهیه می‌کنند و محتویات این مخزن را از طریق منابع مختلف مانند  \lr{Email}   یا بحث‌های آنلاین، فراهم نموده و این مخزن را نگهداری می‌کنند. 
\subsection{نتایج مدیریت فرآیند و پروژه}
اگر درخواست‌های سبک         \LTRfootnote{Vocative}      و مشخصات غیر رسمی برای سازمان وجود داشته باشد، پیچیدگی‌ها زیاد شده و زمانبندی، انتساب وظایف و برآورد هزینه نیز گیج کننده‌تر خواهد بود. مدیران سازمان باید موارد زیر را کنترل نمایند: 
\begin{itemize}
\item فرآیند توسعه کلی 
\item توسعه قانونی نرم‌افزار 
\item کمینه کردن هر فاکتوری که بهره‌وری را کاهش می‌دهد. 
\item در نظر گرفتن اثراتی که با توجه به فرهنگ‌های گوناگون ناشی می‌شوند 
\item وظایف وابسته به هم 
\ item کمینه کردن وابستگی‌های میان گروه‌های توزیع شده
\end{itemize}
\subsection{نتایج فنی }
زمانی که تیم‌ها  در مکان‌های مختلف در حال کار باشند، همزمان  نبودنشان یک عامل بحرانی است. ما باید عملکرد مراحل توسعه را تضمین کنیم و نیز به ازای تمام وظایف، معیارهای ورودی و خروجی را مشخص نماییم. شبکه‌های جهانی، مکان‌های کند و غیر قابل اعتماد     \LTRfootnote{Unreliable}    را پراکنده ساخته‌اند. بنابراین، مدیریت پیکربندی(که شامل ارسال داده‌های بحرانی است) باید با دقت زیادی طرح‌بندی و اجرا شود. 
\subsection{مدیریت ریسک }
مدیریت ریسک، یک فعالیت بحرانی در مدیریت پروژه است. 
فرآیند توسعه توزیع شده نرم‌افزار به عوامل زیر وابسته است: هماهنگی     \LTRfootnote{Coordination،}     تحلیل مسأله ، استخراج نیازمندی‌ها، تقسیم دانش و شناسایی خطرها. در صورتی که پیچیدگی‌ها  زیاد شوند، نقص‌ها        \LTRfootnote{Detect}  نیز افزایش می‌یابند.در اکثر موارد، نقص‌های نرم‌افزاری به مسائل ارتباطی و کمبود آگاهی‌های گروهی مربوط می‌شود و در صورت افزایش پیچیدگی، نقص‌ها نیز افزایش می‌یابند. کنترل نقص‌ها باید در فرآیند مدیریت ریسک گنجانده شود. 
\section{نتایج حاصل از تطبیق  فرآیند توسعه توزیع شده با چابکی} 
متدولوژی‌های چابک فرض می‌کنند که تیم، تنها در یک مکان قرار دارد یعنی جنبه توزیع شده از تیم توسعه را در نظر نمی‌گیرند ولی متأسفانه در واقعیت اوضاع به اینصورت نمی‌باشد. موارد زیر، دلایل گزینش سازمان‌ها به منظور فرآیند توسعه توزیع شده می‌باشند: گسترش کسب و کار به مراکز تجاری جدید(یعنی مراکزی که بصورت فراگیر و ادغام شده می‌باشند)، ایجاد منبعی مؤثر و کارا از کارمندان، هزینه کاهش یافته به وسیله                 \lr{outsourcing}   کردن به ناحیه‌ها و کاهش هزینه‌های سربار .بنابراین نیاز است تا به منظور برطرف نمودن نیازهای صنعت نرم‌افزار، فرآیند توسعه توزیع شده نرم‌افزار را از طریف افزودن فرآیند توسعه چابک نرم‌افزار، گسترش دهیم. متدهای چابک در ترکیب با توسعه توزیع شده، سودمندتر عمل می‌کنند. طبق مطالعات انجام شده، قوانین چابکی می‌توانند بر چالش‌هایی که تیم‌های توزیع شده با آن‌ها مواجه هستند، غلبه نمایند. 
\section{   مزایای حاصل از ترکیب چابکی با فرآیند توسعه توزیع شده }
در توسعه توزیع شده، امکان کمی برای مشاهده حالت پروژه وجود دارد ولی فرآیند چابک، به علت داشتن تکرارهای پیوسته، امکان مشاهده مشکلات قبلی  موجود در مراحل قبلی  را ساده کرده است. بخش مرکزی از متدهای چابک، تکرار پیوسته کدهاست که میزان انجام عمل مدیریت پیکربندی را کاهش می‌دهد. استفاده از متدهای چابک، تأثیرات مثبتی بر ارتباطات میان 
تیم‌ها دارد. مثلا توسعه چرخه‌ای       \LTRfootnote{Development in cycle}      باعث می‌شود که شرکا و همکاران دیگر، اهداف کوتاه‌مدت را راحت‌تر ببینند. زمانی که افراد، اطلاعات موجود درباره ویژگی‌ها را بین یکدیگر تقسیم می‌کنند، بازدید اسپرینت    \LTRfootnote{sprint}       ، راه مؤثری برای پیشرفت ارتباطات است. قوانین چابکی قادرند تا بین فرهنگ‌های مختلف، اطمینان     \LTRfootnote{Trust}     ایجاد کنند و این کار را از طریق داشتن ازتباطات دائمی و تحویل دائمی نرم‌افزار انجام می‌دهند. استفاده از روش‌های      \lr{scrum}    در پروژه، باعث افزایش همکاری بین افراد شده است. همچنین انگیزه  افراد تیم نیز بیشتر شده است. بنابراین ثابت می‌شود که چابکی در تیم‌های توزیع شده، باعث افزایش کیفیت و کارایی         \LTRfootnote{Performance}     می‌شود. 
\section{   چالش‌هایی که تیم‌های چابک توزیع شده با آنها مواجه هستند }
همزمان با اینکه به واسطه ترکیب فرآیند توسعه توزیع شده  نرم‌افزار و متدولوژی چابک سودمندی‌هایی وجود دارد، چالش‌هایی نیز مشاهده می‌شوند. در حالت کلی، توزیع به علت کاهش ارتباطات، باعث عملکرد بد تیم  می‌شود. در صورتی که تیم‌های چابک شدیداً به ارتباط شخص به شخش میان افراد تیم، نیازمندند. بنابراین هنگام تطبیق این دو روش با مشکل روبرو می‌شویم. 
\subsection{مستندسازی }
شرکت‌های    \lr{offshore}   ، طرفدار روش مبتنی بر طرح  \lr{Plan - Driven}      می‌باشند. یعنی درخواست‌ها به تفصیل شرح داده 
می‌شود و طراحی‌ها بصورت      \lr{offshore}    فرستاده می‌شوند تا ایجاد شوند. هنگام توزیع شدن ، تیم‌های موجود در دوردست   ممکن است برخی از جزئیات مربوط به پروژه را از دست بدهند و بنابراین فهم برای آنها مشکل شود. نبودن یک مکالمه قوی ممکن است باعث نارسایی  اطلاعات بین اعضای تیم شود و در نتیجه اعضا باید اطلاعات را کامل نمایند. 
\subsection{برنامه‌نویسی جفتی}
در روش‌های چابک ، اعضای تیم باید با هم روی یک کد واحد کار کنند. انجام این روش در تیم‌های توزیع شده امکانپذیر 
نمی‌باشد . بنابراین باید از روش‌های هم‌ارز  استفاده شود. 
\subsection{ساعت‌های کاری مختلف}
زمانی که تیم‌ها در ناحیه‌های زمانی متفاوت وجود دارند، یک چالش عمده ایجاد می‌شود. زیرا زمان‌هایی پیش می‌آید که یکی از اعضای تیم حاضر است ولی بقیه حاضر نیستند. همسان‌سازی ساعت‌های کاری باعث افزایش وضوح  شده و از دوباره‌کاری  جلوگیری می‌کند. 
\subsection{آموزش روش‌های چابکی}
زمانی که اعضای جدید به تیم‌های دوردست اضافه می‌شوند، آن‌ها باید روش‌های چابکی را آموزش ببینند و چون افراد در  مکان‌های متفاوتند، بنابراین تیم‌های چابک باید به فکر آموزش افراد جدید باشند. در اینصورت تفاوت‌های فرهنگی نیز باعث ایجاد مشکل می‌شود. 
\subsection{توزیع کار}
در حالت معمول، یک داستان کاربر توسط تیم‌های مختلف پیاده‌سازی و کامل می‌رود. بنابراین نهایتاً تکمیل و جمع‌آوری کارهای  انجام شده، پیچیده و دشوار خواهد شد. برای حل این مشکل، تیم باید کارها را طبق موارد زیر میان کاربران تقسیم نماید: داستان واحد و صرفنظر از مکان جغرافیایی، شرایط داستان‌های کاربران و نه مؤلفه‌های سیستمی . در واقع نباید کار را بصورت افقی  تقسیم کنیم. یعنی تقسیم طوری نباشد که یک تیم تنها کار‌های ارائه و تیم دیگر تنها کارهای پایگاه داده را انجام دهد. در حالت کلی یک سازمان با عملکرد کارکنان ترجیح داده می‌شود. تیم‌های دوردست  ، به علت داشتن لایه‌ها  ، مشکلات تیم‌ای تقسیم شده را تشدید می‌کند. پس بهتراست تیم‌های توسعه را بوسیله 
ماژول‌هایی که ارتباط ضعیف    \LTRfootnote{Loosely coupled}     دارند، تقسیم کنیم. 
\section{    ابزارها و تکنیک‌هایی برای پیاده‌سازی فرآیند توسعه چابک توزیع شده نرم‌افزار }
برای ایجاد یک تیم چابک توزیع شده مؤثر، باید بر مشکلات ارتباطاتی که مانع این کار هستند، غلبه نماییم. بسیاری از تیم‌های توزیع شده در عمل شکست خوردند، زیرا آن‌ها مانند تیم‌های مستقر در یک مکان رفتار نمودند. در زیر روش‌هایی برای غلبه بر مشکلات فرآیند توسعه چابک توزیع شده 
نرم‌افزار،     شرح داده شده‌اند:
\begin{itemize}
\item بهبود ارتباطات: ارتباطات بهبود یافته، کلید موفقیت کارهای  توزیع شده تیمی است. این کار باعث می‌شود که تیم‌ها با روش‌های جدید سازگار شوند و عدم فهم  بین گروه‌های ذینفع  کمینه شود.
\item      تمرکز بر آماده‌سازی تیم : بسیاری از روش‌های       \lr{XP}  برای تقویت یکدیگر به کار می‌روند. بنابراین نه تنها یک روش نباید ترک شود، بلکه باید با روش‌های   هم‌ارز جایگزین شود. مثلاً ممکن است که روش برنامه‌نویسی جفتی    \LTRfootnote{ pair programming}  (که استفاده از آن در تیم‌های توزیع شده امکانپذیر نیست) به وسیله روش دوره کردن کدها ، تقویت و جایگزین شود یا ممکن است که کارت‌های مربوط به داستان‌ها      \LTRfootnote{story cards }      به اطلاعات کامل‌تری نیاز داشته باشند که معمولاً از طریق مکالمات، این اطلاعات را دریافت می‌کنند. بهتر است که هر تیم یک مربی  داشته باشد که اصول اساسی را به تیم یادآوری    می‌کند         و     به آن‌ها کمک می‌کند تا روش‌های خود را با روش‌های چابکی وفق دهند و بدین طریق تیم در راه صحیح هدایت می‌شود. 
\item      توزیع کار: از شکستن داستان‌های کاربر به وظایف و سپس تخصیص وظایف بر اساس مکان جغرافیایی و مهارت‌ها اجتناب نمایید. زیرا اجتناب از این امور باعث می‌شود که تیم‌ها، ذخایری از دانش را جمع‌آوری نمایند. در واقع اوضاع نباید طوری باشد که فقط چند نفر خاص توانایی انجام کارهای جدید را داشته باشند. 
\item      مستندسازی: در صورتی که داستان‌های کاربر را با نمودارهای    \lr{use case}   و در بک‌لاگ‌های  \LTRfootnote{ Backlog}  سراسری قابل دسترس فراهم نماییم، این کار باعث کاهش عدم فهم و پیشرفت همکاری سیستم می‌شود. ابزارهایی که عمل پیگیری نتایج را انجام می‌دهند، و نیز ابزارهای پروژه به نگهداری مستندسازی کمک می‌کنند. 
\item      استفاده از ابزارها: ابزارهای مختلف، هم ارتباطات رسمی  وهم ارتباطات غیر رسمی  و نیز پشتیبانی پروژه را پیشنهاد کرده‌اند. اگر تیم‌های چابک در یک مکان نباشند، نمی‌توانند به منظور پیگیری پروژه، بر 
یادداشت‌هایی که درباره یک وظیفه است یا نقشه  موجود روی دیوار، تکیه کنند. همچنین، طراحی‌ها و نمودار‌ها باید در مکان‌های مختلف تقسیم  شوند. 
\end{itemize}
برای توزیع یک تیم، تصمیم  و تعهد  باید بصورت زوج  باشند. این زوج شدن باعث فراهم شدن ابزارهایی می‌شود که این ابزارها، ارتباطات را 
بیشینه می‌کنند. بیشینه شدن اطلاعات باعث بهینه شدن تیم می‌شود. این ابزارها با توجه به عملکرد خود و بصورت زیر دسته‌بندی می‌شوند:
 \subsection{ابزارهای شبکه‌بندی اجتماعی}
 ابزارهای نرم‌افزاری اجتماعی و ابزارهای شبکه‌بندی اجتماعی، تکرارهای گروهی را امکانپذیر می‌سازند. این ابزارها شامل همه چیز از ایمیل گرفته تا ویدئو کنفرانس می‌باشند. 
 \subsection{ابزارهای ارتباطی}
 مانند ایمیل و پیام‌رسان‌های فوری  
 \subsection{ابزارهای مدیریت پیکربندی نرم‌افزار}
 ابزارهایی که ورژن نرم‌افزار و مخازن را کنترل می‌کنند. 
 \subsection{پایگاه داده‌هایی که نتایج و باگ‌ها  را پیگیری می‌کنند}
 شامل اطلاعات باگ‌های پیدا شده می‌باشند. 
 \subsection{مراکز دانش}
 شامل مراجع فنی و سؤالات پرتکرار می‌باشند. 
 \subsection{محیط‌های توسعه همکار}
 فراهم نمودن محیط کاری پروژه و استانداردسازی مجموعه‌های کاری، به عنوان راه‌حل‌های ضروری در پروژه‌های چابک توزیع شده، توصیه شده‌اند.بر اساس گفته \lr{ Fowler }،   \lr{wiki}       ها نیز روش‌هایی برای نگهداری مخازن اطلاعاتی می‌باشند. ويكی مجموعه صفحات وبی ا‌ست كه محتواي آن‌ها بصورت مشاركتی تولید شده و فرایند توسعه آن نیز در مدل مشارکتی توسط مکانیزمی خاص مدیریت می‌شود. مشارکت‌کننده‌ها  می‌توانند بصورت عام و یا کسانی باشند که دسترسی آن‌ها به نرم‌افزار سرويس‌دهنده ويكی مشخص شده است. در واقع ويکي‌ها به کاربران اين اجازه را مي‌دهند که بدون دانش برنامه‌نويسي اقدام به ايجاد صفحات وب درباره موضوعات مختلف بکنند. ويكی‌ها با واسط كاربری نسبتاً ساده‌ای امكان توليد فرامتن و استفاده از زبان‌های نشانه‌گذاری را فراهم می‌آورند و اغلب برای ايجاد پایگاه‌های وب گروهی و ارتقای پایگاه‌های اجتماعی و تحقق مديريت دانش به كار برده می‌شوند. در ویکی کاربران این اجازه را دارند که  محتوای صفحات سایت را ویرایش کنند، صفحات جدید ایجاد کنند و حتی صفحات موجود را حذف کنند. با استفاده از این ویژگی، کاربران می‌توانند به سرعت و بدون نیاز به دانش فنی خاص، درباره موضوعات مختلف صفحاتی را ایجاد کنند و با کمک کاربران دیگر آن‌ها را به مرور زمان کامل کنند.در یک سیستم ویکی، از تمام تغییرات ایجاد شده توسط کاربران، یک نسخه پشتیبان نگاه داشته می‌شود تا در صورت بروز اشتباه و یا هرگونه خرابکاری در محتوای یک ویکی، بتوان به راحتی یک نسخه سالم را جایگزین آن کرد. 
 
 ایجاد ویکی در سازمان‌ها مزایای بسیاری را به همراه دارد، از جمله آن ثبت شدن دانش محدود افراد در موضوعات مختلف و پیوند خوردن این دانش‌های محدود با یکدیگر و تولید دانشی وسیع و جامع در سرتاسر سازمان می‌شود. ویکی باعث می‌شود تا افراد در رقابتی شدید برای تکمیل اطلاعات و اظهار اطلاعات خود در هر زمینه‌ای اعم از حوزه‌های تخصصی سازمان و سایر موارد، قرار گیرند و در نتیجه سازمان از پایگاه داده‌ای مملو از اطلاعات، دانش و تجربیات برخوردار می‌گردد که هر روز نیز بر غنای آن افزوده 
می‌گردد. ویکی‌ها فقط برای استفاده می‌باشند و بصورت طبیعی، غیر ساختمند هستند. این ویژگی یک مزیت دارد و این مزیت این است که هر تیم در طول رشد پروژه ، می‌تواند ساختار مخصوص به خود را برای نگهداری اطلاعات پروژه استفاده نماید. در حال حاضر   ویکی‌پدیا  بزرگترین و معروف‌ترین سایت ویکی است. 
\end{document}