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

· Checkland: متدولوژی ، مجموعه ای از اصول کلی مربوط به روش ها است. که در هر وضعیت مشخص باید به یک روش خاص مناسب به آن وضعیت تبدیل شود.

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

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

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

· هر گاه این رویکرد در حل مسائل سازمانی به کار گرفته شود به عنوان روش کلی حل مسئله نامیده میشود.

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

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

· چگونه پروژه باید به مراحل فرعی تجزیه شود؟

· در هر مرحله چه اقدامیای باید صورت گیرد؟

· در هر مرحله چه خروجی هایی باید تولید شود؟

· در چه زمانی و تحت چه شرایطی باید این وظایف انجام شوند؟

· چه محدودیتهایی باید اعمال شود؟

· چه کسانی باید درگیر شوند؟

· پروژه چگونه باید مدیریت و کنترل شود؟

· از چه ابزارهایی باید استفاده شود؟

دلایل نیاز به متدولوژی

· افزایش هزینه های پروژه نسبت به سقف پیش بینی شده

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

· تولید سیستمهایی که نیاز واقعی کاربران را برآورده نمی کنند

· عدم توانایی در توسعه آتی و یا پشتیبانی مناسب سیستم

· حجم زیاد دوباره کاریها وفعالیتها ی موازی و ناهماهنگ

· عدم وجود ساختاری مناسب برای سازماندهی اطلاعات جمع آوری شده

هدف از به کار گیری متدولوژی ها

· طراحی و یا بهبود فرایند جریان اطلاعات در سیستم

· کاهش هزینه ها در بلند مدت

· راه اندازی سیستمها یی با حداکثر کارایی

· حداقل نیاز به تغییرات در کوتاه مدت

 

متدولوژی های توسعه نرم افزار بطور کلی به دو دسته سنگین وزن (Heavy Weight) و سبک وزن (Light Weight) تقسیم می شود. محور اصلی متدلوژی های سنگین وزن مانند RUP شامل برنامه ریزی جامع و مستند سازی از ابتدا تا انتها و طراحی کامل و گسترده می باشد .به عبارت دیگر روشهای سنگین وزن بصورت پیشگو یا Predictive عمل می کنند یعنی در آغاز همه چیز را پیش بینی می کنند در این جا این سوال پیش می آید که آیا همه چیز از ابتدا قابل پیش بینی می باشد؟

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

چه چیز یک روش توسعه را تبدیل به agile می کند؟

اگر توسعه نرم افزار به صورت :

- افزایشی (incremental) (نشر های کوچک نرم افزاری با گردشهای سریع)

- مشارکتی (cooperative) ( کاربر و توسعه دهندگان با یک ارتباط نزدیک به صورت ثابت با یکدیگرکار می کنند)

- سر راست (straight forward) ( خود روش برای یادگیری و تغییر دادن آسان می باشد و خوب مستند شده است)

- سازگار (adaptive) (قابلیت تغییر پذیری در آخرین لحظات می باشد یعنی انطباق با شرایط)

شود متدلوژی به صورت Agile در می آید .

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

اندازه پروژه :

متدلوژی های سبک وزن بیشتر در پروژه های کوچک استفاده می شوند در حالی که برای پروژه های بزرگ می بایستی از متدلوژی های سنگین وزن استفاده شود ولی این مساله باعث کاهش محبوبیت این متدلوژی ها نمی شود چون تعداد پروژه های کوچک به مراتب بیشتر از پروژه های بزرگ می باشد :)

مدیریت :

در متدلوژی های سنگین وزن مدیریت بصورت مطلق و استبدادی است در حالیکه مدیریت متدلوژی های سبک وزن بصورت غیر متمرکز و آزاد است که این مدیریت غیر متمرکز باعث تصمیم گیری بهتر برای این روش ها می شود.

نحوه مستند سازی :

یکی از عیب های متدلوژی های سنگین وزن مستند سازیهای سنگین می باشد که کار بسیار دشوار و زمانبری می باشد و باید بصورت جامع و کامل انجام شود (مثلا در Rup باید تمامی مستندات برای هر فاز بطور کامل تهیه شود) در حالیکه در متدلوژی های سبک وزن مستند سازی محدود وبسته به نیاز پروژه انجام می شود.

چرخه های توسعه :

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

معیار موفقیت :

در متدلوژی های سنگین وزن معیار موفقیت در راستای طرح اولیه می باشد که در غیر این صورت پروژه به شکست و تحمل هزینه بر خواهد خورد ولی در متدلوژی های سبک وزن معیار موفقیت بر اساس ارزش کاری (Bussiness Value) مشخص می شود که این باعث انعطاف پذیری این متدلوژی ها می شود .در حالیکه در متدلوژی های سنگین وزن به دلیل همان طرح اولیه این انعطاف پذیری وجود ندارد.

اندازه تیم :

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

بازگشت سرمایه : ( بخش مهم :) )

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

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

انواع متدلوژی ها سبک وزن :

XP(Extreme Programming)

Scrum

Crystal Family

FDD(Feature Driven Development)

Dynamic System Development

Adaptive Software Development

Open Source Software Development

 

 

مشخصات متدولوژی های چابک --- منبع : Wikipedia.org

برنامه‌نویسی دو جزئی، یکی از تکنیک‌های توسعه‌ی چابک از طریق XP است. به رادیاتورهای اطلاعات در پس‌زمینه توجه کنید.

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

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

مهم نیست چه دیسیپلین‌های توسعه‌ای لازم است، هر تیم چابک، یک پاسخگوی مشتری دارد. این شخص توسط ذی‌نفعان به نمایندگی انتخاب می‌شود و یک تعهد فردی ایجاد می‌کند که برای پاسخگویی به سؤالات اواسط تکرار، در دسترس توسعه‌دهندگان باشد. [۱۱] در انتهای هر تکرار، ذی‌نفعان و نماینده‌ی مشتریان پیشرفت را بررسی می‌کنند، اولویت‌ها را با دید بهینه‌سازی بازگشت سرمایه (ROI) مجدداً می‌سنجند و از انطباق نیازهای مشتری با اهداف شرکت اطمینان حاصل می‌کنند. بیشتر پیاده‌سازی‌های چابک از ارتباطات غیر رسمی، روزانه و رو در رو در میان اعضای تیم بهره می‌گیرند. این به طور خاص شامل نماینده‌ی مشتری و هر کدام از ذی‌نفعان علاقه‌مند به عنوان ناظر می‌شود. در یک جلسه‌ی مختصر، هر کدام از اعضای تیم گزارش می‌دهند که در روز گذشته چه کرده‌اند، قصد دارند در روز جاری چه کارهایی انجام دهند و موانع پیش روی‌شان کدامند. این ارتباطات رو در رو مشکلات را به محض بروز، افشا می‌کند. «این جلسات روزانه، گاهی به صورت ایستاده یا نشست‌های اسکرام هر روز در یک زمان و مکان ثابت برگزار می‌شوند و نباید بیش از 15 دقیقه طول بکشند. معمولاً جلسات ایستاده این نقش را دارند.»[۱۲]

توسعه‌ی چابک بر کار نرم‌افزار به عنوان مقیاس اصلی پیشرفت تأکید دارد، که با مزیت ارتباطات رو در رو در هم آمیخته شده، و نسبت به سایر متدها مستندات مکتوب کمتری تولید می‌شود. متد چابک ذی‌نفعان را به اولویت‌بندی «خواسته‌ها» با نتایج حاصل از سایر تکرارها، بر اساس ارزش کسب‌وکار مشاهده‌شده در ابتدای تکرار (که با عنوان ارزش‌محور شناخته می‌شود) ترغیب می‌کند.[۱۳]

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

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

در توسعه‌ی چابک نرم‌افزار، یک رادیاتور اطلاعات، صفحه‌نمایشی فیزیکی (معمولاً بزرگ) واقع در صدر دفتر کار است، جایی که رهگذران بتوانند آن را ببینند. این صفحه‌نمایش خلاصه‌ای از آخرین وضعیت محصول(های) نرم‌افزاری را نمایش می‌دهد. این نام توسط Alistair Cockburn ابداع و در کتاب «توسعه‌ی چابک نرم‌افزار» در سال 2002 توصیف شد. [۱۴][۱۵] ممکن است یک نشانگر نوری برای آگاه کردن اعضای تیم در مورد وضعیت فعلی پروژه‌شان به کار رود.

مقایسه با متدهای دیگر

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

 

 

 

خلاصه مقاله : ---منبع parsdata.com

 

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

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

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

 

متدولوژی Agile :

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

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

 

شکست در پروژه ها Agile را بوجود آورد!

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

1- زمانبندی نا مناسب

2- کیفیت پائین در تولید نرم افزار

3- ارتباط نداشتن با مشتری

4- تحلیل نادرست نیازمندی ها

5- کمبود در تست کردن نرم افزار

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

 

نیاز به مستندات در روش Agile الزامی است :

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

 

اصلی ترین بخش : اصول 12 گانه Agile :

این اصول که در سال 2001 توسط مدیران شرکت های نرم افزاری جهت مقابله با شکست در پروژه های نرم افزاری تدوین شده اند عبارتند از :

{به این 12 اصل، مانیفست توسعه چابک نرم افزار هم میگویند که در فوریه 2001 پدید اومد، توی ویکیپدیا کاملتر راجع بهش صحبت شده}

1- بالاترین اولویت در این متدولوژی جلب رضایت مشتری با تحویل زود هنگام نرم افزاری توانمند است.

2- استقبال از تغییر نیازمندی ها، حتی در اواخر فرآیند توسعه.

3- تحویل نرم‌افزار قابل استفاده با فاصله زمانی سه هفته یک بار و یا سه ماه یک بار.

4- ذی نفعان و توسعه دهنده ها می بایست به صورت روزانه در طول پروژه با هم کار کنند.

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

6- کارآمدترین و موثرترین روش انتقال اطلاعات به تیم توسعه و تبادل آن در میان اعضای تیم ، گفتگوی چهره به چهره است.

7- نرم افزار قابل استفاده اصلی ترین معیار سنجش پیشرفت است

8- فرآیند های Agile توسعه پایدار را ترویج می دهند. حامیان مالی، توسعه دهندگان و کاربران باید بتوانند سرعت پيشرفت ثابتی را براي مدت نامحدودی حفظ كنند.

9- توجه مداوم به برتری فنی و طراحی خوب باعث افزایش کیفیت تولید می شود.

10- باید ساده ترین راه که با هدف پروژه سازگار است را انتخاب نمود و از گذاشتن وقت بر روی مشکلاتی که ممکن است در آینده رخ دهد صرف نظر کرد.

11- بهترین مدیریت، تحلیل نیازمندی ها و طراحی از تیم های خود سازمان ده (هرفرد در تیم بر کل پروژه تاثیر دارد) پدید آور می شود. یا گروه‌های خودسازمان‌دهی شده.

12- در فواصل منظم، تیم نشان میدهد که چگونه میتواند در تولید نرم افزار موثرتر باشد و سپس تیم رفتار خود را بر اساس بازتاب این تفکر تنظیم و هم سو می نماید. – یا انطباق با تغییرات و محدودیت‌ها به‌طور منظم.

 

نتیجه گیری

 

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

 

متدولوژی Agile --- منبع Hostiran.net

Agile چیست؟

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

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

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

 

Scrum چیست؟

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

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

مجموعه نیازمندی های عملیاتی و غیر عملیاتی (Functional and NonFunctional Requirements) پروژه، که مستند شده است را backlog گویند. مجموعه نیازمندی هایی که در هر اسپرینت باید تمام شوند sprint Backlog نامیده می شود. هر sprintcycle تا زمانی ادامه پیدا می کند که محصول آماده ارائه باشد. بعد از ارائه محصول ممکن است صاحب پروژه نیازمندی های جدیدی به پروژه اضافه نماید که به آن ها Product Backlog گویند.

مدت زمان هر اسپرینت بستگی به نوع پروژه دارد. این مدت زمان می تواند از یک هفته تا یک ماه متغیر باشد. هر اسپرینت باید دقیقا سر وقت به اتمام برسد و اگر به هر دلیلی در پایان اسپرینت محصول آماده نبود باید نیازمندی های sprint backlog به product backlog منتقل شوند.

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

 

چرا scrum؟

 

تسریع پروسه ارائه محصول

بهبود شیوه کار تیمی

افزایش بهره‎وری نیروی انسانی

کاهش میزان خطا در محصول نهایی

رضایت مشتریان و تطابق با نیاز کاربران

 

 

 

 

تحلیل متدولوژی Agile – منبع پارک دانش

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

تعریف Agile (چابک)

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

تقسیم بندی متدولوژی ها

۱ – سنگین وزن ( Heavy weight ): این متدولوژی ها بیش از اندازه ماشین گرا و مکانیزه بوده و به صورت فرآیندی وارد جزئیات غیر ضروری می شود. فازها به طور کامل اجرا می شوند و مستندات به طور کامل ایجاد می شوند.

۲ – سبک وزن ( Light weight ): در این متدولوژی ، فازها به صورت کوتاه مدت بوده و مستندات به اندازه ایجاد می شوند. متدولوژی چابک در دسته متدولوژی های سبک وزن قرار می گیرد.

مقایسه متدولوژی ها با یکدیگر

روش

معیار موفقیت

اندازه پروژه

سبک مدیریت

چرخه

اندازه تیم

 

• روش

  روش‌های چابک بصورت Adaptive یا سازگار عمل می‌کنند یعنی با شرایط منطبق می‌شوند.

  روش‌های سنگین وزن بصورت پیشگو یا Predictive عمل می‌کنند یعنی در آغاز همه چیز را پیش‌بینی می‌کنند.

  همه چیز از ابتدا قابل پیش‌بینی نیست.

•  

• معیار موفقیت

  معیار موفقیت در روش‌های چابک دستیابی به ارزش کاری (Business Value) است.

  در روش‌های سنگین وزن معیار موفقیت پیش رفتن در راستای طرح اولیه است.

  روش‌های سنگین وزن انعطاف‌پذیری ندارند.

• اندازه پروژه

  اندازه پروژه در روش‌های چابک کوچک است.

  اندازه پروژه در روش‌های سنگین وزن می‌تواند بسیار بزرگ باشد.

  این مسأله از محبوبیت روش‌های چابک نمی‌کاهد (تعداد پروژه‌های کوچک بسیار بیشتر است)

• سبک مدیریت

  مدیریت در روش‌های چابک بصورت غیرمتمرکز و آزاد است.

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

  مدیریت غیرمتمرکز امکان تصمیم‌گیری بهتر را فراهم می‌کند.

•  

• نحوه مستندسازی

  مستندسازی در روش‌های چابک بصورت بسیار محدود انجام می‌شود.

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

  در بسیاری از موارد مستند سازی‌های سنگین, کار بسیار دشوار و زمانبری است.

•  

• چرخه‌ها

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

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

  زمانبر بودن چرخه‌های تولید, موجب طولانی شدن زمان انتظار برای رسیدن به نشرها می‌شود.

•  

• اندازه تیم

  در روش‌های چابک اندازه تیم کوچک است (بین ۲۰ تا ۳۰ نفر).

  در روش‌های سنگین وزن اندازه تیم توسعه بزرگ است.

  خلاقیت و همکاری در تیم کوچک بسیار بیشتر خواهد بود.

•  

• برگشت سرمایه

در روش‌های چابک سرمایه خیلی زود در طول پروژه بر می‌گردد.

در روش‌های سنگین وزن برای برگشت سرمایه باید تا انتهای پروژه صبر کرد.

روش‌های چابک از لحاظ اقتصادی به صرفه‌اند.

Scrum – منبع Wikipedia.org

تعریف

چارچوب یا فرایند مدل اسکرام یک چارچوب تکرارپذیر و افزایشی برای کنترل پروژه (مدیریت نرم‌افزار) است که معمولاً در زیر شاخه مدل فرایند تولید نرم‌افزار چابک و سریع است؛ و یک نوع مدل تولید نرم‌افزار در مهندسی نرم‌افزار بحساب می‌رود.

اسکرام یک چارچوب تولید نرم‌افزار از سری روشهای تفکر چابک (Agile) می‌باشد.

اسکرام یک چارچوب یا فرایند؟ مسئله این است، دراین موضوع کاملاً بین متخصصان اسکرام دوگانگی وجود دارد. اشخاصی مانند کن شوئبر (مبدع اسکرام) دائماً از لفظ چارچوب(framework) استفاده می‌کنند و تاکید می‌نمایند که همه باید این مورد را قبول داشته باشند ولی بعضی دیگر از دوستان از لفظ فرایند و یا متدولوژی برای اسکرام استفاده می‌کنند.

نقش ها

نقش‌های عمده در اسکرام عبارتند از:

Scrum Master که وظیفه نگهداری و حفظ فرایند را برعهده دارد.

Product Owner که نماینده ذینفعان (Stakeholders) پروژه و business است.

Team Member عضوی از یک گروه cross-function است که معمولاً بیش از ۷ نفر نیستند. این افراد عملیات تحلیل٫ طراحی٫ پیاده‌سازی، تست و... را انجام می‌دهند.

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

روند کار اسکرام

مثل تمام متدولوژی‌های Incremental و Iterative در اسکرام نیز دوره‌های زمانی یا iteration داریم که در طی آنها محصول نهایی پروژه بتدریج تکمیل می‌شود. این دوره‌های زمانی را در اسکرام اصطلاحاً sprint نامیده می‌شوند.

در طی یک Sprint که معمولاً یک دوره دو تا چهار هفته است (طول دوره را تیم مشخص می‌کند) اعضاء یک محصول بالقوه قابل ارائه و قابل استفاده را تدریجاً تولید می‌کنند.

اصطلاح Product Backlog نامی است که به بانک اطلاعاتی نیازمندهای عملیاتی و غیر عملیاتی کل یک پروژه اطلاق می‌شود و در حقیقت مجموعه‌ای اولویت بندی شده از نیازمندی‌های سطح بالای سیستمی است که در نهایت بایستی تحویل داده شود.

مواردی از Product Backlog که در طی یک sprint بایستی انجام شود در طول Sprint Planning Meeting مشخص می‌شود. در طول این جلسه، Product Owner اعضاء تیم را دربارهٔ مواردی از Product Backlog آگاه می‌کند. سپس اعضاء تیم مشخص می‌کنند که چه مقدار از موارد مشخص شده توسط Product Owner را می‌توانند در این sprint انجام دهند و چه میزان از آنرا در sprintهای بعدی.

مواردی از Product Backlog که قرار است در یک Sprint انجام شود را اصطلاجاْ Sprint Backlog می‌نامند. مفاد Sprint Backlog در واقع توافقی است بین اعضاء تیم و Product Owner که بعد از تصویب شدن مفاد یک sprint، هیچکس نمی‌تواند آنرا در طول sprint تغییر دهد. در طول دوره، نیازمندی‌های لحاظ شده در Sprint Backlog از Product Backlog حذف می‌شوند. اما امکان دارد به دلایلی که در ادامه می‌آید این نیازمندی‌های دوباره به Product Backlog برگردد.

مانند تمام متدولوژی‌های iterative توسعه نرم‌افزار در اسکرام نیز Time Boxed است، به این معنی که sprint بایستی دقیقاً سروقت تمام شود و اگر نیازمندی‌های اشاره شده در Sprint Backlog به هر علتی تکمیل نشده باشند آنها را کنار گذاشته و دوباره وارد Product Backlog می‌کنند.

بعد از خاتمه یک sprint، اعضاء تیم طی جلسه‌ای به Product Owner و سایر ذینفعان پروژه نشان می‌دهند که چکار کرده‌اند و چطور از نسخه جاری نرم‌افزار می‌شود استفاده کرد.

در ساده‌ترین روش معمولاً از نرم‌افزارهای صفحه گستره (Spread Sheet) همچون LibreOffice Calc یا Microsoft Excel برای ساختن و نگهداری Product Backlog و Sprint Backlog استفاده می‌شود، اما می‌توان از طیف وسیعی از ابزارهای نرم‌افزاری که برای استفاده در تیمهای Agile نوشته شده‌اند نیز استفاده کرد.

برخی از نرم افزارهایی که برای متدولوژی یا فریمورک (چارچوب) Scrum استفاده میشود :

FireScrum

IceScrum

Scrum-Zamurai

Scrumblr

ScrumDo

Scrumforce

Scrumie

Scrumine

Scrum-IT

Scrumwp

Scrum Dashboard

Scrum Time

Scrum Wing 3D