خانه > Agile, Scrum > توسعه نرم افزار Agile

توسعه نرم افزار Agile


Agile Software Development یا توسعه نرم افزار چابک چیست؟

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

اما چه نیازی به روش Agile بود؟! به عبارتی چه شد که این 17 نفر (بعلاوه چند ده نفر دیگر که به صورت غیر مستقیم در این بیانیه تاثیر داشتند) در سال 2001 اقدام به انتشار چنین روشی کردند!؟

جواب کاملا واضح است: ضعف های موجود در روش های سنتی باعث شد که این دوستان روش Agile را معرفی نمایند.

روش های سنتی و یا موجود چه مشکلاتی داشتند؟

روش های موجود آن زمان (و فعلی این زمان ایران) که بیشتر به صورتی فاز به فاز عملیات اجرا می شد و نتیجه کار از قبل به صورت یک طراحی اولیه دقیق (Up-front Design) پیش بینی می شد یک سری ایراد اساسی و کلی داشت :

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

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

به این دلیل که عملکرد این پروسه ها بر اصل Anticipation یا پیش بینی استوار بود. در Anticipation یک سری موارد بر روی کاغذ و به عنوان قرار داد بسته جهت پیاده سازی تحویل تیم توسعه داده می شد و تیم توسعه موظف می شد در یک زمان مقرر و با یک منابع مشخص و ثابت این وظایف را پیاده سازی نماید. این اصل  همراه خود در بردارنده طراحی دقیق اولیه یا Big Design Up-Front بود (همان صحبت معروفی که شاید شنیده باشید :»ما اگر 1 سال وقت داشته باشیم 10 ماه آن را برای تحلیل و طراحی و  2 ماه آن را برای پیاده سازی صرف می کنیم).

Big Design Up-Front خوب است ولی در جایی که همه چیز ثابت باشد و نیازی به تغییر نداشته باشیم ولی آیا به راستی در جهان واقع و در اکثر پروژه هامان نیاز به تغییر نداریم؟!

زمانیکه در پروژه ای Up-Front Design می شود مسلما فاز تست آخرین فازی خواهد شد که بر روی محصول انجام می شود. ولی آیا این فاز تاثیر گذار می تواند باشد؟ محصولی که کامل ساخته شده است تزریق کیفیت به آن ساده نیست و در بعضی از موارد غیر ممکن خواهد بود. بهتر است به جای این , محصول با کیفیت ساخته شود و نه کیفیت به آن در آخر پروژه تزریق شود.

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

رد کردن تغییر به منزله ناکارآمد کردن محصول و خروجی پروژه می باشد. هر تغییر و یا اصلاحی که در محصول نیاز می شود برای تکمیل و کارآمدتر کردن آن می باشد : به این دلیل که مشتری نیازمند تغییر است (زیرا تجارت او در حال تغییر است و یا اصلا او در شناخت نیازها اشتباه کرده است و یا هر چیز دیگری)  و اگر تغییر انجام نشود محصول به درد تجارت و کسب وکار مشتری نخواهد خورد و اگر تغییر نیز انجام شود هزینه آن بالا خواهد بود , که در این صورت هم پروژه به صرف نخواهد بود.

یکی دیگر از معایب اصلی Anticipation جلوگیری از به وجود آمدن  نوع آوری در محصول می باشد. یعنی عملا نوع آوری وجود نخواهد داشت.

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

نقطه عکس حالت Anticipation حالت Adaptation می باشد که Agile بر آن استوار می باشد.

در Adaptation به جای یک طراحی دقیق و برای سازگاری بیشتر محصول با نیاز های واقعی مشتری از Real-Time Planning و Emergent Design استفاده می شود. یعنی به حد کافی در زمان های مناسب نیازمندی هایی از طریق ارتباط چهره به چهره دائم و فیدبک مشتری دریافت می شود که فقط آنها بر اساس عکس بزرگ محصول برنامه ریزی و طراحی می شوند و نه بیشتر.

Iterative و Incremental بودن روش Agile فرصت مغتنمی برای ایجاد یک بستر Adaptation به وجود آورده است. بدین صورت که محصول به صورت Incremental ساخته می شود و در Iterative های معلوم و کوتاه در اختیار مشتری قرار داده می شود  در هر تکرار و یا چرخش فیدبک های مشتری به عنوان نیازمندی های جدید وارد پروسه توسعه می شوند که بدلیل فیدبک های دائم و زود هزینه تغییرات بسیار پایین خواهد آمد.

علاوه بر این در Agile بدلیل Incremental بودن , پروسه آزمایش  و یا Test به صورت یکپارچه با توسعه بخش ها انجام می شود که این نوید دهنده یک محصول با کیفیت در هر Release خواهد بود. به عبارت ساده تر به جای تزریق کیفیت ,  بخش ها را با کیفیت می سازیم که این هم هزینه نگه داری هر بخش را کاهش می دهد و هم محصول نهایی با کیفیت می شود و هم تغییرات قابل اجرا خواهند بود. در حالی که در روش Anticipation پروسه Test در فاز آخر انجام می شد.

به طور کلی برای ویژگی یک متد بر پایه Adaptation می توان موارد زیر را بر شمرد :

  • Real-Time Planning
  • Emergent Design
  • Integrated Testing
  • Collaborative Discussions
  • Just-in-Time & Just-Enough Requirements

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

ارزش های توسعه نرم افزار چابک

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

با وجود اینکه در موارد سمت چپ ارزش هایی وجود دارد ولی
موارد سمت راست ارزش بیشتری برای ما دارند

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

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

همه این مواردی که ذکر شد ارزش هایی می باشند که انتظار می رود یک سازمان چابک برای خود داشته باشد. ولی اینها وحی منزل نیستند و سازمان ها می توانند ارزش های خود را برای چابک سازی خود داشته باشند.

در کنار ارزش های سازمان چابک 12 اصل چابک نیز وجود دارد که سازمان های چابک برای دست یابی به ارزش های چابک می توانند پیرو آن اصول باشند:

اصول بیانیه چابک
ما از این اصول پیروی می کنیم :

بالاترین اولویت ما رضایت مشتری از طریق
تحویل به موقع و مداوم نرم افزار ارزشمند می باشد

پذیرائی از نیازهای در حال تغییر , حتی آن هایی
که در اواخر توسعه پدید آور می شوند. فرآیند های چابک
تغییرات را جهت رقابت بر سر مشتری مهار و کنترل می نمایند

تحویل نرم افزار کارکننده غالبا از چند هفته تا چند ماه
یک بار انجام می شود که زمانبندی کوتاه تر ترجیح داده می شود

ذینفعان تجاری و توسعه دهندگان باید هر روزه در
طول پروژه با هم کار کنند

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

کارآمدترین و موثرترین روش برای انتقال و رساندن
اطلاعات به تیم توسعه , گفتگوی چهره به چهره و رودرو می باشد

نرم افزار کارکننده اصلی ترین معیار پیشرفت می باشد

فرآیند های چابک توسعه پایدار را ترویج می دهند.
حامیان مالی , توسعه دهندگان و کاربران باید قادر به
حفظ سرعت پیشرفت ثابتی براى يک مدت نامحدود باشند

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

اصل سادگی ضروری می باشد

بهترین معماری ها , نیاز مندی ها و طراحی ها از تیم های
خود سازمانده پدید آور می شود

در فواصل منظم , تیم برچگونگی موثرتر شدن تامل وتفکر می نماید
و سپس تیم رفتار خود را بر اساس بازتاب این تفکر تنظیم و هم سو می نماید

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

اما چگونه می توان چابک شد ؟

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

برای اینکه بتوان به سطحی از چابکی دست یافت می توان از Practice های Agile مانند Scrum , XP , Crystal و یا … بهره جست . در همین رابطه پیشنهاد می کنم این مطلب را مطالعه کنید: ربط اسکرام با Agile.

نتیجه گیری

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

یاشیاسیز

  1. دسامبر 8, 2010 در 6:32 ب.ظ.

    با سلام
    با تشکر از مطالب مفیدتون در مورد Agile Devlelopment می خواستم در خواست کنم در مورد EssUP که ظاهرا شاخه ای از Agile توضیحاتی بیان کنید.

    • دسامبر 9, 2010 در 7:54 ق.ظ.

      EssUP یا همان Essential Unified Process یک مدل بهبود یافته از پروسه RUP می باشد . این مدل زیر شاخه Agile نیست و در محافل و دنیای Agile پروسه شناخته شده ای نیست. و به هیچ وجه Agile مردان این مدل را به عنوان فرزندی از نسل متدهای Agile نه می شناسند و نه قبول دارند.
      نه تنها این زیر شاخه Agile نمی باشد بلکه می توان گفت خود این مدل بهبود یافته در برگیرنده Agile می باشد(به نقل از مبدع) . به طور خلاصه سعی شده است از مزایای Agile و Lean در این بهبود استفاده شود که به نظر من با روح نسخه پیچی RUP باز همچنان در فاز فضایی باقی خواهد ماند.

      موفق باشید

  2. مارس 6, 2012 در 7:48 ب.ظ.

    سلام
    من مدتیه دارم درباره ی اسکرام تحقیق می کنم (برای درس نرم 1) ، انصافا دستتون درد نکنه تنها مطالب فارسی رو شما قرار دادید.( البته خیلی خوب و قابل فهم)
    ولی کاش این مطالب رو روی یک وبلاگ فارسی قرار می دادید تا همه بتونن استفاده کنند (به خاطر فیلتر wordpress)

    دانشجوی ترم 4 مهندسی فناوری اطلاعات pnu

  1. دسامبر 13, 2010 در 3:47 ب.ظ.
  2. دسامبر 31, 2010 در 6:10 ق.ظ.
  3. آوریل 10, 2011 در 10:48 ق.ظ.

پاسخی بگذارید

در پایین مشخصات خود را پر کنید یا برای ورود روی شمایل‌ها کلیک نمایید:

نشان‌وارهٔ وردپرس.کام

شما در حال بیان دیدگاه با حساب کاربری WordPress.com خود هستید. بیرون رفتن / تغییر دادن )

تصویر توییتر

شما در حال بیان دیدگاه با حساب کاربری Twitter خود هستید. بیرون رفتن / تغییر دادن )

عکس فیسبوک

شما در حال بیان دیدگاه با حساب کاربری Facebook خود هستید. بیرون رفتن / تغییر دادن )

عکس گوگل+

شما در حال بیان دیدگاه با حساب کاربری Google+ خود هستید. بیرون رفتن / تغییر دادن )

درحال اتصال به %s

%d وب‌نوشت‌نویس این را دوست دارند: