بخشی از مقاله
چکیده :
توسعه نرم افزار به عنوان فرایندی متدولوژی محور در سالهای اخیر به سمت استفاده و بهره گیری از متدولوژی های چابک در حرکت است. این متدولوژی ها با عنایت به ویژگی ها و ارزشهای خاص تعریف در آنها به طور ویژه در مورد تیم ها و پروژه های کوچک و متوسط کارایی مناسبی دارند. اما در این میان، استفاده از چابکی در مقیاس بزرگ به عنوان یک چالش و حوزه پر اهمیت مطرح بوده است. این مقاله به طور ویژه بر روی مقیاس پذیری چابکی در توسعه نرم افزار متمرکز شده است. مطالعه حاضر نشان می دهد که برای رفع چالش مقیاس پذیری در چابکی مدلها و چارچوبهایی اختصاصی ارائه شده است که هر کدام سعی در افزایش کاربرد متدولوژی های چابک در حوزه ای وسیع تر دارند. این مطالعه همچنین نشان دهنده چالشهایی ذاتی است که به نظر می رسد چابک مقیاس پذیر با آنها سر و کار خواهد داشت و در مواردی موجب کاهش چابکی تیم و فرایند توسعه نرم افزار خواهند گردید.\
کلمات کلیدی: توسعه نرم افزار چابک، متدولوژی های چابکی، مقیاس پذیری چابکی، چابک مقیاس پذیر، چالشهای مقیاس پذیری
-1 مقدمه
صنعت مهندسی نرم افزار، به عنوان یک صنعت پیشرو که بخش عمده ای از فناوری های نوین بشری مدیون آن است، به شدت متکی بر روشها و مدلهای توسعه نرم افزار است. این روشها به طور کلی در قالب متدولوژی های توسعه نرم افزار شناخته می شوند. نکته مهم در این میان، تنوع متدولوژی های توسعه نرم افزار می باشد. صنعت نرم افزار پس از چندین دهه که از روشهای مبتنی بر طرح و برنامه استفاده می نمود، در نهایت به سمت استفاده از متدولوژی های سبک وزن گام نهاد. متدولوژی های سبک وزن که امروز از آنها به عنوان متدولوژی های چابک یاد می شود، از اواخر قرن گذشته پا به عرصه وجود گذاشتند و در سال 2001 به طور رسمی و طی بیانه چابک به صنعت نرم افزار معرفی شدند .[1] این متدولوژی ها در واقع در پی ناکارآمدی متدولوژی های پیشین که امروزه به عنوان متدولوژی های سنتی نیز شناخته می شدند معرفی شدند. در این متدولوژی های نوظهور اساس توسعه نرم افزار بر مبنای اصول و ارزشهای نوینی که ساختار توسعه محصول را متحول می نمودند، بنا شده است.
در این میان، به شرایط و مسائلی توجه شده است که به نوعی توسعه محصول و ساختار تیمی را نیز محدود به وجود این شرایط نموده است. به عنوان مثال، توجه به تیم های کوچک، خلاقیت های انسانی، خودسازمان دهی تیم ها، کنترل محدود ساختار تیمی، توجه به رهبری تیم ها به جای مدیریت و ریاست بر آنها و محدودیت مستندات محدودیت هایی را برای بهره گیری از این متدولوژی ها ایجاد می نماید .[2] تجربه چندین ساله استفاده از متدولوژی های چابکی نشان از کارآمدی آنها در تامین ارزشهای مورد نظر مشتری، دستیابی به کیفیت مناسب محصول توسعه یافته، رضایت مشتری و ارزشهایی از این دست دارد. هر چند که به نظر می رسد تبعیت از ارزشهای چابکی، استفاده از این متدولوژی ها را محدود به پروژه های کوچک می نماید .[3]
به منظور بررسی دقیق تر این موضوع مطالعات متعددی در چند سال اخیر انجام شده است که برخی از این مطالعات حکایت از مشکلات بهرهگیری از متدهای چابک در محیط ها و پروژه های بزرگ دارند. برخی دیگر نیز به ارائه راهکارهایی در این خصوص پرداختهاند .[4] چنین مطالعاتی بحث ویژه مقیاسپذیری در توسعه چابک را به طور ویژه دنبال نمودهاند. منظور از مقایسپذیری، افزایش و گسترش کاربرد این متدها از بعد اندازه تیمی، گستره توزیع تیمی و در نهایت اندازه پروژه در حال توسعه می باشد.
مطالعه حاضر به طور ویژه مروری بر مطالعات انجام شده در حوزه مقیاس پذیری چابکی خواهد داشت و سعی در شفاف سازی جنبه های مختلف این مساله در توسعه نرم افزار دارد. بدین لحاظ ادامه این مقاله در بخشهای زیر سازمان دهی شده است. بخش دوم به معرفی اجمالی متدولوژی های چابک و ارزشهای چابکی پرداخته شده است. بخش سوم به مساله مقیاس پذیری در توسعه چابک می پردازد و در ادامه در بخش بعدی مزایا و چالشهای مقیاس پذیری بررسی می شوند. بخش پنجم نتیجه مقاله را در برخواهد داشت.
-2 توسعه نرم افزار چابک
متدولوژی های چابک طیف وسیعی از روشهای توسعه نرم افزار را شامل می شود که همه آنها در التزام به ارزشهای چابکی معرفی شده در بیانه چابک یکسان هستند. این متدولوژی ها هر کدام از جنبه خاصی بر توسعه نرم افزار تمرکز دارند. به عنوان مثال متدولوژی اسکرام از چارچوبی بهره مند است که مدیریت پروژه های نرم افزاری را تحت پوشش قرار میدهد.[3] در همین حال، متدولوژی XP به طور خاص تمریناتی را ارائه می کند که در آنها توسعه نرم افزار مورد توجه است. متدولوژی های چابکی همگی در زیر مجموعه چتر چابکی قرار دارند با نام هایی چون اسکرام، XP، TDD، DSDM، FDD و مواردی این چنینی شناخته می شوند.[2]
متدولوژی های چابک، بر اساس توجه به اصولی بنا شده اند که در راس آنها توجه به افراد و تیم های توسعه نرم افزاری با کمترین سطح بروکراسی قرار دارد. در این متدها فرض بر استفاده از نیرو های خلاق و مجرب انسانی است که با همکاری با یکدیگر در یک محیط یکجا و با بهره گیری از ارتباطات چهره به چهره سعی در توسعه محصول نرم افزاری دارند. در این تفکر، مشتریان نیز به عنوان بخشی از تیم توسعه، تیم فنی را در مراحل مختلف توسعه نرم افزار یاری می کنند. در واقع نقش مشتری در توسعه محصول و ایجاد ارزشهای تجاری نقشی ممتار و منحصر به فرد است. در این متدولوژیها، تاکید ویژه ای بر مشارکت افراد و ارتباطات انسانی شده است. به همین دلیل، با لحاظ چنین فضای ارتباطی و بهره گیری از متخصصین چند وظیفه ای، توسعه محصول با لحاظ کمترین مستندات و فراورده های غیرضروری انجام می گیرد.[3]
اندازه تیم های توسعه نرم افزار در متدولوژی های چابک عمدتا از انگشتان دست فراتر نمی روند. به همین دلیل، می توان امکان بروز خلاقیت های انسانی و عدم نیاز به مدیریت در این تیم ها را انتظار داشت. در این فضا، افراد از طریق دریافت راهنمایی لازم، به صورت خود سازمان دهی شده توسعه نرم افزار را پیش خواهند برد. روشن است که این امر در نهایت ممکن است به عنوان محدودیتی برای گسترش ابعاد تیمی به شمار آید.نکته مهم دیگر در این متدولوژی ها، پذیرش و استقبال از تغییرات مورد درخواست مشتریان است. این امر چنان مورد تاکید و تمرکز این متدولوژی ها است که اکوسیستم توسعه محصول را به طور ویژه ای تحت تاثیر قرار داده است.
در این متدولوژی به صورت ویژه درخواست های تغییر دریافتی از سوی مشتریان در هر مرحله از توسعه محصول مورد استقبال قرار می گیرند. در واقع وجود نیازمندیهای غیر قطعی و عدم کنترل تغییرات نیازمندی ها خود یکی از محرک های اصلی طراحی و پیشنهاد این متدولوژی ها بوده است. جدول فوق نشان از ویژگی هایی دارد که شاید در دنیای واقعی وبه دلیل نبود این ویژگی ها، بکارگیری این متدولوژی ها را محدود به پروژه های کوچک که نفرات محدودی را نیازمند هستند نماید. این امر، در تضاد با خواسته بسیاری از تیم ها است. به همین دلیل مساله مقیاس پذیری در مورد متدهای چابک مطرح شده و مورد توجه محققین و مهندسان نرم افزار بوده است.
-3 مقیاس پذیری در چابکی
چنانچه ذکر گردید، مطالعات پیشین حکایت از توفیق متدولوژی های چابک در اجرای پروژه های کوچک و متوسط داشته که همین امر جذابیت مناسبی برای استفاده از این متدها در شرکتهای نرم افزاری ایجاد کرده است .[5] هر چند در عمل، بهره گیری از این متدها چندان هم بی دردسر و ساده نبوده و گاها تیم ها و شرکتهای نرم افزاری با چالشهایی جدی نیز مواجه می باشند. با اینحال، گرایش
کلی شرکتهای نرم افزار - فارغ از اندازه این شرکتها - ، استفاده از این متدولوژی ها برای همه پروژه های خود می باشد. از این منظر، بهره گیری از این متدها باید فراتر از محدودیت های ذاتی این متدها در بکارگیری در پروژه های کوچک باشد . چالش مقیاس پذیری در این متدها در واقع تمرکز بر این مساله دارد.
-1-3 سطح مقیاس
یکی از سوالاتی که در زمینه مقیاس پذیری چابکی مورد توجه است، داشتن تعریفی مناسب از مقیاسپذیری و سطح مقیاس میباشد. شاید به درستی نتوان به این سوال جواب داد که حوزه گسترش چابکی تا چه حدی است و اصولا این متدها تا چه اندازه قابل استفاده در محیطهای بزرگ هستند. توجه به این مساله که مقیاسپذیری در عمل در تضادی آشکار با چابکی وعده دادهشده توسط متدهای چابک است، موجب میشود که در مقیاس پذیری هر حرکتی توام با احتیاط باشد. به عنوان یک دریافت عمومی می توان از موارد زیر در مورد مقیاس پذیری چابکی به عنوان معیارهای مناسب یاد کرد ,4] .[6 هر چند که چنانچه ذکر کردید به دلیل ماهیت این مساله، این موارد بیشتر رهیافت های شهودی در این مورد می باشند.
در یک معیار، داشتن بیش از 5 تیم که متشکل از حدود 50 نفر باشند یکی از مصداق های بزرگی در چابکی است. در عین حال، وجود این تعداد توسعهدهنده که برروی محصولی با بیش از یک و نیم میلیون خط کد کار میکنند نیز نشانهای از مقیاس بزرگ در چابکی است. در یک نگاه دیگر، تمرکز بر بیش از یک تیم، یک محصول و یا یک پروژه میتوان مصداقی از بزرگی در چابکی باشد. همچنین الزام به وجود اسکرامی از اسکرامها میتواند نشانه ای دیگر در این مورد باشد. همه این موارد در کنار یکدیگر نیز نشانهای از چابکی مقیاسپذیر شده می باشند. توجه به این مساله در این زمینه ضروری است که توفیق در چابک مقیاس پذیر به نوعی وابستگی جدی به ایجاد زیرساخت مناسب برای آن، ارائه آموزشهای لازم و وجود توانمندیهای پرسنلی دارد .[7 ,4]