مهندسی نرم افزار چابک چیست؟ ترجمه پرسمن

مهندسی‌نرم افزار چابک ترکیبی از مجموعه فلسفه و راهنماهای توسعه است. فلسفه آن مبتنی بر رضایت مشتری و تحویل گام به گام محصول است. تیم‌های پروژه‌ای چابک، از مجموعه کوچکی از افراد که انگیزه بالایی دارند تشکیل شده است، متدهای آن غیر رسمی است و کارهای مهندسی نرم‌افزار کمینه روی محصول صورت می‌گیرد و تحویل نرم‌افزار به ساده‌ترین شکل ممکن است. راهنما و دستورالعمل‌های توسعه بسیار روی تحلیل و طراحی تأکید می‌کنند و به هیچ عنوان این فعالیت‌ها کسل کننده نیستند.خوب چه کسانی درگیر این مهندسی نرم‌افزار چابک هستند، جواب واضح است، همگی از مهندس نرم‌افزار گرفته، تا مشتری و مدیر پروژه و کاربران همه آن در یک تیم چابک با هم کار می‌کنند. این تیم، تیمی است که خودسازمنده و سرنوشت خودش را خودش می‌سازد. قوی بودن همکاری و ارتباطات در یک تیم چابک بسیار مهم است.در محیط‌های کامپوتری مدرن که بذر سیستم‌های مبتنی بر کامپیوتر در آن پاشیده شده است، توسعه محصول نرم‌افزاری بسیار سریع و در عین حال بسیار در حال تغییر است. مهندسی نرم‌افزار چابک یک جایگزین منطقی برای مهندسی نرم‌افزار سنتی است. در عمل اثبات شده است که این روش منهدسی نرم‌افزار در تحویل موفق و سریع محصول کارا بوده است.مهندسی نرم‌افزار چابک چه مراحلی دارد– شاید بهتر باشد به جای اینکه بگوییم مهندسی نرم‌افزار چابک، مهندسی نرم‌افزار ساده. گام‌های تولید محصول در این شیوه مهندسی عبارتند از: ارتباطات، برنامه‌ریزی، مدل‌سازی، ساخت و استقرار. اما این مراحل به شکل کمینه در می‌آیند به گونه‌ای که تمرکز تیم روی ساخت و تحویل محصول باشد.محصول کاری‌مان چیست؟ اولین و مهم‌ترین نرم‌افزاری است که در تاریخ معین به مشتری تحویل می‌دهیم. البته تحویل نرم‌افزار به صورت افزایشی (گام به گام) است. علاوه بر این محصول اسناد مهم مرتبط با نرم‌افزار و موارد آزمون صورت گرفته تولید می‌شود.از کجا بدانیم که در مسیر درست قرار داریم؟ اگر تیم چابک موافق است که کار در حال پیشرفت است و تیم نرم‌افزار قابل تحویل به صورت افزایش در تاریخ معین تحویل مشتری می‌دهد، خیالتان راحت باشد شما در مسیر درست قرار دارید.مهندسی نرم‌افزار چابکایده اصلی که منجر به توسعه چابک شد موجب توسعه روش‌های چابک برای فایق آمدن بر ضعف‌های مهندسی‌نرم افزار سنتی شد. توسعه چاب مزیت‌هایی دارد، ولی ممکن است برای برخی افراد، وضعیت‌ها یا محصول‌ها جواب ندهد. مهندسی نرم‌افزار چاب مخالف مهندسی نرم‌افزار سنتی نیست بلکه می‌تواند به عنوان یک فلسفه فراگیر برای کار نرم‌افزاری استفاده شود.در اقتصاد مدرن، پیش‌بینی اینکه چطور یک سیستم مبتتنی بر کامپیوتر (مانند برنامه‌های موبایل) در طول زمان تکامل می‌یابد مشکل است. شرایط بازار به سرعت تغییر می کنند، نیازهای کاربر به تدریج مشخص می‌شوند و تهدیدهای رقابتی جدید به آنکه خبر کنند ظاهر می‌شوند. در برخی شرایط، نمی‌شود نیازمندی‌ها را قبل از شروع پروژه تعیین کرد. شما باید به اندازه کافی برای پاسخ دادن به یک محیط کسب و کاری سیال (مایع) چابک باشید.سیال بودن یعنی تغییر، و تغییر گران است مخصوصاً اگر کنترل نشود یا ضعیف کنترل شود. یکی از ویژگی‌های بارز روش چابک، کاهش هزینه تغییر در طول فرایند توسعه نرم‌افزار است.و اما یک نکته دیگر و آن اینکه، آن‌ها که نرم‌افزار را می‌سازند آدم هستند و نه ربات. انسان‌ها ویژگی‌ها متفاوتی دارند، هیچ دو انسانی نمی‌یابید که به یک اندازه مهارت، خلاقیت، اعتماد به نفس، مهارت ارتباطی، نظم و انواع چیزهای انسانی دیگری به اندازه هم داشته باشند و مهندسین نرم‌افزار هم مستثنی نیستند. باید این مهندسین نرم‌افزار در مواقع مورد نیاز انگیزه بگیرند و تشویق شوند و یا هم که باید ضعف‌های آن‌ها را تحمل کنید.چابک چیست؟چابک همان‌طور که از اسمش برمی‌آید یعنی آنکه فرز و سریع باشید. به قول هلالیخوش خرامی ز آب نازک‌ترتیزگامی ز باد چابک‌ترولی بیاییم بنگریم این چابکی در دنیای مهندسی نرم‌افزار چیست. برخی اعتقاد بر آن دارند که چابکی باید فراگیر باشد. برخی دگر گویند، که مهندسین نرم‌افزار بایستی هم‌پای تغییرات راه روند و سریع‌تر از تغییرات باشند.اما چابکی چیزی بیشتر از پاسخ به تغییرات است. قبل از آنکه به تغییرات پاسخ داد باید تیمی ساخته شود که اعضای بسیار خوب با هم رابطه برقرار می‌کنند (بدانید که این اعضا شامل همه آدم‌ها و فردهایی می‌شود که به گونه‌ای در ساخت نرم‌افزار شرکت داشته‌اند یا با آن کار می‌کنند، بنگرید آنان چه کسانند.)از دیگر اصول چابکی آن است که نرم‌افزار سریع تحویل مشتری دهیم و همیشه بر این تکیه می‌کند که یک چیز تقریباً خوب تحویل دهید (و نه الزاماً کاملاً خوب). در یک فرایند چابک، ما و شما نداریم. یعنی مشتری خودش در ساخت نرم‌افزار شرکت می‌کند و مهندس نرم‌افزار با همکاری مشتری محصول را می‌سازد. یکی از اصول مهم چابکی آن است که باید بدانیم که برنامه‌ریزی در یک دنیای نامطمئن محدودیت‌ها دارد و بدین جهت باید منعطف بود.چابکی می‌تواند در هر فرآیند نرم‌افزاری به کار برده شود. با این حال، برای به سر بردن آن، لازم است فرآینده به گونه‌ای طراحی شود که تیم پروژه بتوانند کارهایشان را سازگار کنند، ساده‌ کنند و به روشی که سیالیت رهیافت توسعه چابک قابل درکت باشد انجام دهند. روی محصولات کاری ضروری تکیه کنند و استراتژی تحویل گام به گام که باعث می‌شود مشتری در پاسخ به نوع محصول و نوع محیط عملیات منعطف باشد تمرکز کنند.چابکی و هزینه تغییررهیافت سنتی توسعه نرم‌افزار معروف به این است که هزینه تغییر همچنان که پروژه رشد می‌کند به صورت غیر خطی افزایش می‌یابد. معمولاً انجام تغییر در زمان گردآوری نیازمندیها (که دراوایل پروژه صورت می‌گیرد) آسان است. یک سناریو کاربرد شاید نیاز باشد اصلاح شود، لیستی از توابع توسعه داده شود یا یک مشخصه نوشته شده ویرایش شد. این هزینه‌ها معمولاً کم هستند و زمان مورد نیاز برای آن تأثیر چندانی در زمان تحویل محصول نمی‌گذارد.اما فکر کنید چه اتفاقی می‌افتد که یک سهام‌دار اصلی نرم‌افزار پس از چند ماه پس از شروع پروژه بیاید و بگوید دوستان یک چند تغییر مهم می‌خواهم در این پروژه بدهید. تیم وسط تست‌های تأیید است (که معمولاً در پایان پروژه است) و اعضای تیم به هم می‌گویند این مردک نمی‌داند که ما کارمان را تمام کردیم و حالا از خواب بلند شده و می‌گوید بیایید چیزی بدان اضاف کنید. این تغییرات نیاز به اصلاح طراحی معماری نرم‌افزار، طراحی و ساخت سه مولفه جدید، اصلاح پنج مولفه دیگر، طراحی تست‌ها جدید و … دارد. طبیعتاً اینجا هزینه‌ها بسیار بالا می رودو زمان مورد نیاز برای تضمین اینکه یک محصول با کیفیت تحویل داده شود نیز بسیار بالا می‌رود.برای حل این مشکل، مهندسین نرم‌افزار جهان راهکاری پدید آوردند به نام مهندسی نرم‌افزار چابکبیک کرشمه که کردی هزار دل بردیتبارک الله ازین چابکی و چالاکیاین مهندسین اعتقاد راسخ بر آن دارند که اگر فرایند توسعه نرم‌افزار چابک به درستی پیاده شود، هزینه تغییر نرم‌افزار در طول فرایند ساخت هموار یا یکنواخت است. ابزارهایی که چابک برای این کار دارد عبارتند از، تحویل گام به گام محصول، تست‌های مداوم یونیت‌ها، برنامه‌نویسی موازی. حالا شاید یک کم اغراق کردند و واقعاً شیب هزینه به تغییر یکنواخت نباشد ولی به هر حال نسبت به روش سنتی هزینه تغییر در روش چابک بسیار کم‌تر است.ویژگی‌های پروژه‌هایی که مهندسی نرم‌افزار چابک به دردشان می‌خوردهر فرایند چابک برای پروزه‌هایی به کار می‌رود که یک سری ویژگی‌ها دارند که اهم آن‌ها به شرح زیر هستند:۱. پیش‌بینی اینکه کدام نرم‌افزار به قوت خویش باقی می‌ماند و کدام تغییر می‌یابد دشوار است. و به همان اندازه پیش‌بینی اولویت‌های مشتری نیز دشوار است.۲. برای برخی نرم‌افزارها طراحی و ساخت درهم تنیده هستند. هر دو فرایند طراحی و ساخت باید پشت سرهم انجام شوند تا مدل طراحی ثابت شود. در این پروژه‌ها پیش‌بینی اینکه چقدر از ساخت باید انجام شود تا مدل طراحی به حالت ثابت برسد مشکل است.۳. تحلیل، طراحی، ساخت و آزمون آنچنان که خواستاریم قابل پیش‌بینی نباشند.در اینجا یک سؤال مهم برمی‌خیزد، چطور پروژه‌ای را مدیریت کنیم که قابل پیش‌بینی نیست؟ ولی ما قبلاً جوابش را گفتیم جوابش سازگاری فرایند است (توانایی پاسخ به تغییرات شرایط فنی)، پس نتیجه اینکه یک فرایند چابک باید سازگار adaptable باشد.اما، این انطباق در زمانی که پیشرفت رو به جلویی نباشد به چه کار می‌آید. پس باید یک گزینه دیگر در این چابکی خویش بنهیم به نام incredementaly یعنی افزایشی یا پله پله ای. خوب حالا برای رسیدن به سازگاری افزایشی (حالا شما هر چه می‌خواهید معنی کنید) تیم چابک به یک چیز خیلی مهم به نام بازخورد مشتری نیاز دارد.یک کاتالیزور خوب برای گرفتن بازخورد مشتری ایجاد نمونه اولیه یا ساخت قسمتی از سیستم عملیاتی است. در اینجا باید از استراترژی incremental development به معنای توسعه پله پله‌ای استفاده کنیم. یک نرم‌افزار پله‌پله‌ای باید به صورت مکرر با فواصل زمانی کوتاه تحویل مشتری شود تا با تغییرات و چیزهای غیرقابل پیش‌بینی بتوان شمشیر مقابله را تیز کرد. با این رهیافت مشتری می‌تواند درستی محصول را به صورت پله‌ای بررسی کند و بازخوردهای لازم به تیم بدهد.اصول چابکیموسسان و مهم‌انی که روش چابکی را ایجاد کردند، ۱۲ اصل را بیان کردند که اگر شرکت یا پروژه‌ای این ۱۲ اصل را داشت می‌توان بر آن مهر چابکی زد. این ۱۲ اصل به طور خلاصه اینجا آورده می‌شود تا خواننده ما بداند که شرکت او می‌تواند این مهر را بگیرد یا خیر.اول آنکه رضایت مشتری با تحویل زود هنگام نر‌م‌افزار فراهم می‌آید. برای رسیدن به این مهم، چابکی‌ها باید نیازمندی‌هایی که تغییر می‌یابند را بشناسند و با دیگر شریک داران در تولید یک نرم‌افزار با سرعت‌ترین زمان ممکن که یک چیز درست هم باشد گپ بزنند.دوم اینکه، یک تیم چابک بایستی مجموعه‌ای از افراد با انگیزه باشد، در این تیم افراد با یکدیگر رو در رو ملاقات می‌کنند و در محیطی که برای توسعه نرم‌افزاری با کیفیت بالا فرآهم آمده شده همکاری می‌کنند. این تیم رهرو فرایندی است که برتری فنی را می‌ستاید و به طراحی خوب دل می‌بنند و در عین حال سادگی را می‌پسندد و اعتقاد دارد که سادگی یعنی به حداکثر رساندن میزان کار انجام نشده.سوم آنکه یک تیم چابک «خود سازمانده» است. تیمی که معماری خوب ساختار یافته‌ای توسعه می‌دهد که در اثر آن طراحی‌های محکم حاصل می‌شود و رضایت مشتری به دست می اید. بخشی از فرهنگ تیم به درون‌گرایی می‌نگرد و همیشه به دنبال بهبود کارهایی است که هدف اصلی را نشانه می‌گیرند.خوب درست است که در اینجا سه تا آوردیم ، اما از درون این سه آن دوازده برمی‌خیزد. نکته‌ای که دانستن آن نیک است آنکه انواع مدل‌های چابک داریم، اهمیت همه آنچه که در بالا آوردیم نزد آن‌ها کم و زیاد می‌شود، اما همه این اصول را دارند حالا هر چند بهایی سنگینی بدان ندهند.با این حال، مانند هر رویکرد دیگری، منهدسی نرم‌افزار چابک نیز منتقدان خودش را دارد. ولی کس مخالف چابکی نیست. سؤال این است که به چه روشی می‌توانیم این چابکی به دست آوریم. به خاطر داشته باشید که کار کردن نرم‌افزار مهم است. اما نرم‌افزار ویژگی‌هایی چون قابلیت اطمینان، قابلیت استفاده، قابلیت نگهداری و ویژگی‌های کیفی نیز داشته باشد.هیچ پاسخ کاملی به این موضوع‌ها وجود ندارد. حتی در دنیای چابکی‌ها انواع مدل‌های چارچوب وجود دارد که هر یک رهیافت متفاوتی برای حل این مسائل دارند.در هر مدل مجموعه‌ای از «ایده‌ها» وجود دارد (آژیلیست‌ها دوست ندارند آن‌ها را «وظایف کاری» بنامند) که نشان‌دهنده انحراف قابل توجهی از مهندسی نرم‌افزار سنتی است. و با این حال، بسیاری از مفاهیم چابک صرفاً اقتباسی از مفاهیم خوب مهندسی نرم افزار هستند. نتیجه این است که با در نظر گرفتن بهترین هر دو مکتب می توان چیزهای زیادی به دست آورد و با تحقیر هر یک از این رویکردها تقریباً چیزی به دست نمی آید.