engeneer_19
19th September 2009, 04:06 PM
@};-@};-شیوه‌ای جدید در تولید نرم‌افزار@};-@};-
● Agile Software Development
قصد دارم یکی از مباحث جدید در مهندسی نرم‌افزار را به صورت مختصر توضیح دهم. این مدل تولیدی نرم‌افزار را بارها در پروژه‌های نرم‌افزاری‌ای که مدیریت و اجرا کرده‌ام اعمال کردم و تجربه نشان داده است که خیلی از مواقع این روش توانسته است گوی سبقت را از روش‌های معمول و متداول برباید.
در طراحی یک نرم‌افزار رعایت اصول استاندارد طراحی، استفاده از الگوهای آماده و بهره‌گیری از روش‌های نوین بسیار مهم است، ولی نکته مهم این است که در اصل کاربران، باعث می‌شوند یک پروژه نرم‌افزاری به نتیجه برسد. یعنی فناوری و پروسه استفاده شده، در حقیقت در رده دوم اهمیت قرار دارند.
بسیاری از ما با پروژه‌های نرم‌افزاری‌ای که بدون هیچ‌گونه اصولی تهیه می‌شوند، مواجه شده‌ایم و دیده‌ایم که کار با این گونه پروژه‌ها تا چه اندازه مشکل است. در این پروژه‌ها مشکلات عمده‌ای که پیش میآیند عبارتند از: عدم توانایی تولیدکنندگان در تشخیص نیازهای کاربران، وجود ایرادها و error های تکراری، تأخیر در ارائه محصول و... . از طرف دیگر، مشتریان این‌گونه نرم‌افزارها از عدم دقت در ارائه برنامه زمانبندی دقیق از طرف طراحان سیستم، کیفیت کمِ نرم‌افزارهای تولیدی و افزایش هزینه‌ها شکایت دارند.
در این پروژه‌ها برنامه‌نویسان ساعت‌های زیادی را صرف تهیه نرم‌افزاری می کنند که مملو از مشکل است و تلاش آنان چنان که باید، مؤثر نیست. وقتی با این مشکلات مواجه می‌شویم، به این فکر می‌افتیم که باید در کار خود روش و رویه‌ای درست داشته باشیم که فعالیت‌های مربوط به پروژه در آن مشخص و منظم باشد، نیازهای کاربران در آن مشخص باشد و خروجی نرم‌افزار و محصولات پروژه با موفقیت تولید شوند.
برای این کار می‌توانیم به تجربیات کسب شده در پروژه‌های گذشته خود مراجعه کنیم و فعالیت‌های موفقی که در آن پروژه‌ها انجام شده است را دوباره انجام دهیم و از کارهایی که باعث مشکل در آن پروژه‌ها گشته‌اند، پرهیز کنیم. البته نمی‌توانیم با این کار از وجود مشکل در نرم‌افزار خود مطمئن باشیم؛ زیرا مشکلات، چه بخواهیم چه نخواهیم، بروز خواهند کرد و از آن جایی که در کار رویه‌ای ثابت نداریم و تنها از تجربیات قدیمی خود استفاده می‌کنیم، نمی‌توانیم انتظار داشته باشیم که نرم‌افزارهای ما بدون اشکال باشند؛ زیرا ممکن است با مشکلی برخورد کنیم که تا به حال با آن برنخورده‌ایم و تجربه‌ای در رفع آن نداریم.
اوایل سال ۲۰۰۱ تعدادی از محققان و صاحب‌نظران نرم‌افزار، گروهی به نام Agile Alliance را تشکیل دادند که توانست راه‌حلی برای تیم‌های نرم‌افزاری پیدا کند تا به سرعت و با کیفیت بالا نرم افزار تولید کنند و بتوانند اگر تغییری در قسمتی از نرم‌افزار به وجود آمد، آن را کنترل کنند و اصلاحات لازم را اعمال نمایند. آن‌ها مدعی هستند که راه بهتری برای تولید نرم‌افزار پیشنهاد کرده‌اند که کار ما برنامه‌نویسان را آسان کرده است.
آن‌ها چند اصل مهم را به عنوان مانیفیست یا بیانیه خود در نظر گرفته‌اند. از جمله: اهمیت نقش اعضای تیم در پروژه نرم‌افزاری، تولید مستندات مناسب برای نرم‌افزار، اهمیت نقش کاربران سیستم و استفاده از آن‌ها در مراحل ساخت نرم‌افزار، و توانایی اعمال تغییرات در نرم‌افزار در تمامی مراحل تولیدی آن.
● اهمیت نقش اعضای تیم در پروژه نرم‌افزاری
یک رویه صحیح و مناسب در تولید نرم‌افزار به تنهایی نمی‌تواند از شکست پروژه جلوگیری نماید، اگر از افراد مناسب در پروژه استفاده نشود. البته انتخاب رویه‌ای نامناسب نیز می‌تواند باعث عدم کارایی اعضای تیم شود؛ حتی اگر بسیار کارکشته هم باشند. به طوری که حتی گروهی از بهترین برنامه‌نویسان نیز اگر در تیم منسجم کار نکنند، نمی‌توانند تمام کارایی خود را در اختیار پروژه قرار دهند.
یک عضو مؤثر و قوی در تیم نیازی ندارد که یک برنامه‌نویس سطح بالا و قوی باشد. او می‌تواند یک برنامه‌نویس معمولی باشد، اما کسی باشد که با دیگر اعضای تیم به خوبی کار کند و با آنان رابطه خوبی داشته باشد. یک تیم با برنامه‌نویسان معمولی‌ای که می‌توانند به صورت منسجم کار کنند و با هم ارتباط خوبی داشته باشند، بهتر از گروهی از بهترین برنامه‌نویسان است که نمی توانند کار تیمی انجام دهند و با موفقیت پروژه‌ای را به اتمام برسانند.
البته نباید نقش مهم ابزارهای برنامه‌نویسی مناسب و ابزار CASE را در موفقیت پروژه‌های نرم‌افزاری نادیده گرفت. کامپایلرها، IDEها، سیستم‌های کنترلی سورس کدهای برنامه و ... همگی می‌توانند باعث شوند اعضای تیم به خوبی و با دقت بیشتری کار خود را انجام دهند. البته استفاده زیاد از ابزارهای برنامه‌نویسی و کمکیِ مهندسان نرم‌افزار می‌تواند اثر معکوس نیز داشته باشد. یکی از نکات قابل اهمیت که مدیران پروژه‌ها باید بدانند این است که اولین کاری که باید انجام دهند، ایجاد تیمی مناسب برای پروژه است؛ حتی قبل از این‌که محیط کاری مناسب را برای آن تیم فراهم آورند. ابتدا باید تیمی کارا و همگام با هم تشکیل داد. سپس اجازه داده شود خود اعضای آن تیم در مورد نیازهای ابزاری و محیطی خود تصمیم بگیرد.
● تولید مستندات
نرم‌افزار بدون مستندات را می‌توان مانند خانه‌ای تجسم کرد که نقشه سیم‌کشی برق، لوله‌کشی و هیچ‌گونه نقشه دیگری ندارد. حال تجسم کنید که اگر قسمتی از برق این ساختمان ایراد پیدا کند، چه کاری می‌توانیم انجام دهیم؟ یا باید از برقکاری که آن ساختمان را قبلاً برق کشی کرده است درخواست کنیم که به ما کمک کند (البته پیدا کردن او نیز کار آسانی نیست و ممکن است هیچ‌وقت او را پیدا نکنیم). راه‌حل بعدی این است که دیوارهای خانه را خراب کنیم تا سیم‌ها را پیدا کنیم و نقص سیم‌کشی را برطرف نماییم و به این صورت در حقیقت یک فاجعه به تمام معنی برای صاحبخانه پیش میآید.
برای پیدا کردن اشکالی کوچک یا ارتقای سیستم برقی چه مشکلاتی سر راه خواهند بود؛ اگر نقشه برق ساختمان موجود نباشد. حال تجسم کنید نرم‌افزاری فاقد مستندات باشد و برنامه‌نویس آن نیز در دسترس نباشد.
کدهای برنامه نمی‌توانند به تنهایی و بدون راهنما و مستندات توسط دیگر افراد قابل فهم باشند. طراحان نرم‌افزار باید مستنداتی فراهم کنند که بتواند به کسی که بعدها به آن کدها مراجعه می‌کند نشان دهد که طراحان اولیه این سیستم چگونه ساختار برنامه را درست کرده‌اند. البته درست کردن مستنداتِ زیاد و غیرضروری کار درستی نیست و وقت تلف کردن است.
مهندسان نرم‌افزار اصطلاح خوبی برای مستندات دارند و می‌گویند: مستندات نرم‌افزار باید <کوتاه> و <ساکت> باشد. منظور از کوتاه این است که باید مختصر و دقیق باشد و منظور از ساکت این است که نباید خیلی به جزئیات غیرضروری بپردازد و خواننده را خسته نماید.
● اهمیت نقش کاربران سیستم در پروژه
نرم‌افزار را نمی‌توان مانند اجناس دیگر سفارش داد. نمی‌توانید انتظار داشته باشید که شرح فنی نرم‌افزاری را بنویسید و از کسی بخواهید آن را در مدت زمان معین و با قیمت معین به اتمام برساند. پروژه‌های نرم‌افزاری که این‌گونه سفارش داده شده‌اند، اکثراً شکست خورده‌اند. پروژه‌های موفق پروژه‌هایی هستند که در آن کاربران به صورت مستقیم در مراحل اجرایی پروژه دخیلند و نظرات مشتریان که همان کاربران سیستم باشند، از ابتدا مورد توجه قرار گرفته است. اگر کاربران سیستم در تمامی مراحل تولید نرم‌افزار حضور داشته باشند و در مورد کار و محصول به دست آمده تا آن زمان اعلام نظر کنند، می‌توان مطمئن بود پس از اتمام کار انتظار بالاتری از سیستم نخواهد داشت.
● توانایی اعمال تغییرات در نرم‌افزار و برنامه‌ریزی موقت
به راستی می‌توان عامل موفقیت یا عدم موفقیت یک پروژه نرم‌افزاری را در توانایی یا عدم توانایی آن در پاسخ به تغییرات دانست؟ برنامه اجرایی پروژه باید انعطاف‌پذیری مناسبی داشته باشد و بتوان آن را متناسب با تغییرات احتمالی آینده تغییر داد. معمولاً مدیران پروژه‌ها چارت و برنامه زمانبندی پروژه را روی دیوار نصب می‌کنند. با این کار می‌توانند تکالیف هر شخص در تیم را کنترل نمایند و قسمت‌های انجام شده را با خط قرمز روی آن برنامه مشخص کنند. اما مشکلی که در این قسمت ممکن است پیش آید این است که بعد از مدتی ساختار این برنامه به هم خواهد خورد؛ چرا که اولاً اعضای تیم در مورد پروژه اطلاعات خوبی کسب کرده‌اند و برخی از تکالیف آنان غیرضروری خواهد شد.
از طرف دیگر، مشتری و کاربران آینده سیستم نیز در جریان کار قرار می‌گیرند و ممکن است نیازهای خود را افزایش دهند و تکالیف بیشتری برای اعضای تیم به ارمغان بیاورند. با این کار تمام برنامه زمانبندی پروژه به هم خواهد خورد. راه بهتری که می‌توان پیش گرفت این است که برنامه‌ای دقیق برای مثلاً دوهفته در نظر بگیریم، برنامه‌ای تقریبی برای دو یا سه ماه آینده مشخص کنیم و برنامه‌ای باز هم تقریبی‌تر برای بعد از آن. دلیل منطقیِ این‌گونه برنامه‌ریزی این است که با این کار می‌توانیم اگر مثلاً نیازهای کاربر تغییر کرد، در مرحله بعدی برنامه خود آن تغییر را در نظر بگیریم.
● اصول تولید نرم‌افزار به روش Agile Development
▪ جلب رضایت کاربر سیستم با ارائه نرم‌افزارهای با کیفیت
▪ نیازهای کاربران ممکن است عوض شود؛ حتی در مراحل پایانی پروژه. در Agile Development گروه آمادگی قبول هرگونه تغییری را در هر مرحله از پروژه دارد.
▪ تولید سریع نرم‌افزار با تبدیل آن به چند قطعه و ارایه آن به مشتری
▪ ایجاد محیط کاری مناسب برای اعضای تیم در پروژه
▪ یکی از بهترین روش‌ها برای گرفتن اطلاعات و تبادل آن، ایجاد ارتباط گفتاری با دیگر اعضای تیم در پروژه است.
▪ در پروژه‌هایی که به روش Agile تولید می‌شوند، معیار موفقیت پروژه و رویه انتخابی، میزان رضایت مشتری از نرم‌افزار تولید شده و نیازهایی است که برآورده شده‌اند.
▪ اعضای تیم در این روش در کار خود آهسته و پیوسته عمل می‌کنند.
▪ اعضای تیم در این روش باید بیشترین تلاش خود را برای نوشتن نرم‌افزارهایی با کیفیت بالا به عمل آورند.
▪ انتخاب بهترین و آسان‌ترین راه برای رسیدن به هدف اصلی پروژه
در حقیقت هدف اصلی هر برنامه‌نویس و تمامی تیم‌های نرم‌افزاری، ارائه بهترین سرویس و محصولی با کیفیت بالا به مشتریان خود است. Agile Software Development راهی است برای رسیدن به این منظور. چندین روش مانندScrum ،Adaptive Software Development و Extreme Programming) XP) می‌توانند به شما کمک کنند.
نرم‌افزارهایی با کیفیت بالا بسازید و اطمینان حاصل کنید که پروژه نرم‌افزاری شما با موفقیت به پایان می‌رسد. اگر می‌خواهید در مورد روش‌های ذکر شده اطلاعات بیشتری کسب نمایید می‌توانید، به مقاله‌ای با همین قلم با نام <مناسب‌ترین روش برای تولید نرم‌افزارهای کوچک> در شماره ۶۶ ماهنامه مراجعه کنید.
ماهنامه شبکه
{happy}
● Agile Software Development
قصد دارم یکی از مباحث جدید در مهندسی نرم‌افزار را به صورت مختصر توضیح دهم. این مدل تولیدی نرم‌افزار را بارها در پروژه‌های نرم‌افزاری‌ای که مدیریت و اجرا کرده‌ام اعمال کردم و تجربه نشان داده است که خیلی از مواقع این روش توانسته است گوی سبقت را از روش‌های معمول و متداول برباید.
در طراحی یک نرم‌افزار رعایت اصول استاندارد طراحی، استفاده از الگوهای آماده و بهره‌گیری از روش‌های نوین بسیار مهم است، ولی نکته مهم این است که در اصل کاربران، باعث می‌شوند یک پروژه نرم‌افزاری به نتیجه برسد. یعنی فناوری و پروسه استفاده شده، در حقیقت در رده دوم اهمیت قرار دارند.
بسیاری از ما با پروژه‌های نرم‌افزاری‌ای که بدون هیچ‌گونه اصولی تهیه می‌شوند، مواجه شده‌ایم و دیده‌ایم که کار با این گونه پروژه‌ها تا چه اندازه مشکل است. در این پروژه‌ها مشکلات عمده‌ای که پیش میآیند عبارتند از: عدم توانایی تولیدکنندگان در تشخیص نیازهای کاربران، وجود ایرادها و error های تکراری، تأخیر در ارائه محصول و... . از طرف دیگر، مشتریان این‌گونه نرم‌افزارها از عدم دقت در ارائه برنامه زمانبندی دقیق از طرف طراحان سیستم، کیفیت کمِ نرم‌افزارهای تولیدی و افزایش هزینه‌ها شکایت دارند.
در این پروژه‌ها برنامه‌نویسان ساعت‌های زیادی را صرف تهیه نرم‌افزاری می کنند که مملو از مشکل است و تلاش آنان چنان که باید، مؤثر نیست. وقتی با این مشکلات مواجه می‌شویم، به این فکر می‌افتیم که باید در کار خود روش و رویه‌ای درست داشته باشیم که فعالیت‌های مربوط به پروژه در آن مشخص و منظم باشد، نیازهای کاربران در آن مشخص باشد و خروجی نرم‌افزار و محصولات پروژه با موفقیت تولید شوند.
برای این کار می‌توانیم به تجربیات کسب شده در پروژه‌های گذشته خود مراجعه کنیم و فعالیت‌های موفقی که در آن پروژه‌ها انجام شده است را دوباره انجام دهیم و از کارهایی که باعث مشکل در آن پروژه‌ها گشته‌اند، پرهیز کنیم. البته نمی‌توانیم با این کار از وجود مشکل در نرم‌افزار خود مطمئن باشیم؛ زیرا مشکلات، چه بخواهیم چه نخواهیم، بروز خواهند کرد و از آن جایی که در کار رویه‌ای ثابت نداریم و تنها از تجربیات قدیمی خود استفاده می‌کنیم، نمی‌توانیم انتظار داشته باشیم که نرم‌افزارهای ما بدون اشکال باشند؛ زیرا ممکن است با مشکلی برخورد کنیم که تا به حال با آن برنخورده‌ایم و تجربه‌ای در رفع آن نداریم.
اوایل سال ۲۰۰۱ تعدادی از محققان و صاحب‌نظران نرم‌افزار، گروهی به نام Agile Alliance را تشکیل دادند که توانست راه‌حلی برای تیم‌های نرم‌افزاری پیدا کند تا به سرعت و با کیفیت بالا نرم افزار تولید کنند و بتوانند اگر تغییری در قسمتی از نرم‌افزار به وجود آمد، آن را کنترل کنند و اصلاحات لازم را اعمال نمایند. آن‌ها مدعی هستند که راه بهتری برای تولید نرم‌افزار پیشنهاد کرده‌اند که کار ما برنامه‌نویسان را آسان کرده است.
آن‌ها چند اصل مهم را به عنوان مانیفیست یا بیانیه خود در نظر گرفته‌اند. از جمله: اهمیت نقش اعضای تیم در پروژه نرم‌افزاری، تولید مستندات مناسب برای نرم‌افزار، اهمیت نقش کاربران سیستم و استفاده از آن‌ها در مراحل ساخت نرم‌افزار، و توانایی اعمال تغییرات در نرم‌افزار در تمامی مراحل تولیدی آن.
● اهمیت نقش اعضای تیم در پروژه نرم‌افزاری
یک رویه صحیح و مناسب در تولید نرم‌افزار به تنهایی نمی‌تواند از شکست پروژه جلوگیری نماید، اگر از افراد مناسب در پروژه استفاده نشود. البته انتخاب رویه‌ای نامناسب نیز می‌تواند باعث عدم کارایی اعضای تیم شود؛ حتی اگر بسیار کارکشته هم باشند. به طوری که حتی گروهی از بهترین برنامه‌نویسان نیز اگر در تیم منسجم کار نکنند، نمی‌توانند تمام کارایی خود را در اختیار پروژه قرار دهند.
یک عضو مؤثر و قوی در تیم نیازی ندارد که یک برنامه‌نویس سطح بالا و قوی باشد. او می‌تواند یک برنامه‌نویس معمولی باشد، اما کسی باشد که با دیگر اعضای تیم به خوبی کار کند و با آنان رابطه خوبی داشته باشد. یک تیم با برنامه‌نویسان معمولی‌ای که می‌توانند به صورت منسجم کار کنند و با هم ارتباط خوبی داشته باشند، بهتر از گروهی از بهترین برنامه‌نویسان است که نمی توانند کار تیمی انجام دهند و با موفقیت پروژه‌ای را به اتمام برسانند.
البته نباید نقش مهم ابزارهای برنامه‌نویسی مناسب و ابزار CASE را در موفقیت پروژه‌های نرم‌افزاری نادیده گرفت. کامپایلرها، IDEها، سیستم‌های کنترلی سورس کدهای برنامه و ... همگی می‌توانند باعث شوند اعضای تیم به خوبی و با دقت بیشتری کار خود را انجام دهند. البته استفاده زیاد از ابزارهای برنامه‌نویسی و کمکیِ مهندسان نرم‌افزار می‌تواند اثر معکوس نیز داشته باشد. یکی از نکات قابل اهمیت که مدیران پروژه‌ها باید بدانند این است که اولین کاری که باید انجام دهند، ایجاد تیمی مناسب برای پروژه است؛ حتی قبل از این‌که محیط کاری مناسب را برای آن تیم فراهم آورند. ابتدا باید تیمی کارا و همگام با هم تشکیل داد. سپس اجازه داده شود خود اعضای آن تیم در مورد نیازهای ابزاری و محیطی خود تصمیم بگیرد.
● تولید مستندات
نرم‌افزار بدون مستندات را می‌توان مانند خانه‌ای تجسم کرد که نقشه سیم‌کشی برق، لوله‌کشی و هیچ‌گونه نقشه دیگری ندارد. حال تجسم کنید که اگر قسمتی از برق این ساختمان ایراد پیدا کند، چه کاری می‌توانیم انجام دهیم؟ یا باید از برقکاری که آن ساختمان را قبلاً برق کشی کرده است درخواست کنیم که به ما کمک کند (البته پیدا کردن او نیز کار آسانی نیست و ممکن است هیچ‌وقت او را پیدا نکنیم). راه‌حل بعدی این است که دیوارهای خانه را خراب کنیم تا سیم‌ها را پیدا کنیم و نقص سیم‌کشی را برطرف نماییم و به این صورت در حقیقت یک فاجعه به تمام معنی برای صاحبخانه پیش میآید.
برای پیدا کردن اشکالی کوچک یا ارتقای سیستم برقی چه مشکلاتی سر راه خواهند بود؛ اگر نقشه برق ساختمان موجود نباشد. حال تجسم کنید نرم‌افزاری فاقد مستندات باشد و برنامه‌نویس آن نیز در دسترس نباشد.
کدهای برنامه نمی‌توانند به تنهایی و بدون راهنما و مستندات توسط دیگر افراد قابل فهم باشند. طراحان نرم‌افزار باید مستنداتی فراهم کنند که بتواند به کسی که بعدها به آن کدها مراجعه می‌کند نشان دهد که طراحان اولیه این سیستم چگونه ساختار برنامه را درست کرده‌اند. البته درست کردن مستنداتِ زیاد و غیرضروری کار درستی نیست و وقت تلف کردن است.
مهندسان نرم‌افزار اصطلاح خوبی برای مستندات دارند و می‌گویند: مستندات نرم‌افزار باید <کوتاه> و <ساکت> باشد. منظور از کوتاه این است که باید مختصر و دقیق باشد و منظور از ساکت این است که نباید خیلی به جزئیات غیرضروری بپردازد و خواننده را خسته نماید.
● اهمیت نقش کاربران سیستم در پروژه
نرم‌افزار را نمی‌توان مانند اجناس دیگر سفارش داد. نمی‌توانید انتظار داشته باشید که شرح فنی نرم‌افزاری را بنویسید و از کسی بخواهید آن را در مدت زمان معین و با قیمت معین به اتمام برساند. پروژه‌های نرم‌افزاری که این‌گونه سفارش داده شده‌اند، اکثراً شکست خورده‌اند. پروژه‌های موفق پروژه‌هایی هستند که در آن کاربران به صورت مستقیم در مراحل اجرایی پروژه دخیلند و نظرات مشتریان که همان کاربران سیستم باشند، از ابتدا مورد توجه قرار گرفته است. اگر کاربران سیستم در تمامی مراحل تولید نرم‌افزار حضور داشته باشند و در مورد کار و محصول به دست آمده تا آن زمان اعلام نظر کنند، می‌توان مطمئن بود پس از اتمام کار انتظار بالاتری از سیستم نخواهد داشت.
● توانایی اعمال تغییرات در نرم‌افزار و برنامه‌ریزی موقت
به راستی می‌توان عامل موفقیت یا عدم موفقیت یک پروژه نرم‌افزاری را در توانایی یا عدم توانایی آن در پاسخ به تغییرات دانست؟ برنامه اجرایی پروژه باید انعطاف‌پذیری مناسبی داشته باشد و بتوان آن را متناسب با تغییرات احتمالی آینده تغییر داد. معمولاً مدیران پروژه‌ها چارت و برنامه زمانبندی پروژه را روی دیوار نصب می‌کنند. با این کار می‌توانند تکالیف هر شخص در تیم را کنترل نمایند و قسمت‌های انجام شده را با خط قرمز روی آن برنامه مشخص کنند. اما مشکلی که در این قسمت ممکن است پیش آید این است که بعد از مدتی ساختار این برنامه به هم خواهد خورد؛ چرا که اولاً اعضای تیم در مورد پروژه اطلاعات خوبی کسب کرده‌اند و برخی از تکالیف آنان غیرضروری خواهد شد.
از طرف دیگر، مشتری و کاربران آینده سیستم نیز در جریان کار قرار می‌گیرند و ممکن است نیازهای خود را افزایش دهند و تکالیف بیشتری برای اعضای تیم به ارمغان بیاورند. با این کار تمام برنامه زمانبندی پروژه به هم خواهد خورد. راه بهتری که می‌توان پیش گرفت این است که برنامه‌ای دقیق برای مثلاً دوهفته در نظر بگیریم، برنامه‌ای تقریبی برای دو یا سه ماه آینده مشخص کنیم و برنامه‌ای باز هم تقریبی‌تر برای بعد از آن. دلیل منطقیِ این‌گونه برنامه‌ریزی این است که با این کار می‌توانیم اگر مثلاً نیازهای کاربر تغییر کرد، در مرحله بعدی برنامه خود آن تغییر را در نظر بگیریم.
● اصول تولید نرم‌افزار به روش Agile Development
▪ جلب رضایت کاربر سیستم با ارائه نرم‌افزارهای با کیفیت
▪ نیازهای کاربران ممکن است عوض شود؛ حتی در مراحل پایانی پروژه. در Agile Development گروه آمادگی قبول هرگونه تغییری را در هر مرحله از پروژه دارد.
▪ تولید سریع نرم‌افزار با تبدیل آن به چند قطعه و ارایه آن به مشتری
▪ ایجاد محیط کاری مناسب برای اعضای تیم در پروژه
▪ یکی از بهترین روش‌ها برای گرفتن اطلاعات و تبادل آن، ایجاد ارتباط گفتاری با دیگر اعضای تیم در پروژه است.
▪ در پروژه‌هایی که به روش Agile تولید می‌شوند، معیار موفقیت پروژه و رویه انتخابی، میزان رضایت مشتری از نرم‌افزار تولید شده و نیازهایی است که برآورده شده‌اند.
▪ اعضای تیم در این روش در کار خود آهسته و پیوسته عمل می‌کنند.
▪ اعضای تیم در این روش باید بیشترین تلاش خود را برای نوشتن نرم‌افزارهایی با کیفیت بالا به عمل آورند.
▪ انتخاب بهترین و آسان‌ترین راه برای رسیدن به هدف اصلی پروژه
در حقیقت هدف اصلی هر برنامه‌نویس و تمامی تیم‌های نرم‌افزاری، ارائه بهترین سرویس و محصولی با کیفیت بالا به مشتریان خود است. Agile Software Development راهی است برای رسیدن به این منظور. چندین روش مانندScrum ،Adaptive Software Development و Extreme Programming) XP) می‌توانند به شما کمک کنند.
نرم‌افزارهایی با کیفیت بالا بسازید و اطمینان حاصل کنید که پروژه نرم‌افزاری شما با موفقیت به پایان می‌رسد. اگر می‌خواهید در مورد روش‌های ذکر شده اطلاعات بیشتری کسب نمایید می‌توانید، به مقاله‌ای با همین قلم با نام <مناسب‌ترین روش برای تولید نرم‌افزارهای کوچک> در شماره ۶۶ ماهنامه مراجعه کنید.
ماهنامه شبکه
{happy}