Agile Software Development
امين صفايي ماهنامه شبکه
در اين شماره براي دومين يادداشت از صفحه <كدنبشته> قصد دارم يكي از مباحث جديد در مهندسي نرم‌افزار را به صورت مختصر توضيح دهم. در يادداشت‌هاي بعدي نيز سعي خواهم كرد اصول و روش هاي آن را شرح دهم. اين مدل توليدي نرم‌افزار را بارها در پروژه‌هاي نرم‌افزاري‌اي كه مديريت و اجرا كرده‌ام اعمال كردم و تجربه نشان داده است كه خيلي از مواقع اين روش توانسته است گوي سبقت را از روش‌هاي معمول و متداول بربايد. در طراحي يك نرم‌افزار رعايت اصول استاندارد طراحي، استفاده از الگوهاي آماده و بهره‌گيري از روش‌هاي نوين بسيار مهم است، ولي نكته مهم اين است كه در اصل كاربران، باعث مي‌شوند يك پروژه نرم‌افزاري به نتيجه برسد. يعني فناوري و پروسه استفاده شده، در حقيقت در رده دوم اهميت قرار دارند. بسياري از ما با پروژه‌هاي نرم‌افزاري‌اي كه بدون هيچ‌گونه اصولي تهيه مي‌شوند، مواجه شده‌ايم و ديده‌ايم كه كار با اين گونه پروژه‌ها تا چه اندازه مشكل است. در اين پروژه‌ها مشكلات عمده‌اي كه پيش ميآيند عبارتند از: عدم توانايي توليدكنندگان در تشخيص نيازهاي كاربران، وجود ايرادها و error هاي تكراري، تأخير در ارائه محصول و... . از طرف ديگر، مشتريان اين‌گونه نرم‌افزارها از عدم دقت در ارائه برنامه زمانبندي دقيق از طرف طراحان سيستم، كيفيت كمِ نرم‌افزارهاي توليدي و افزايش هزينه‌ها شكايت دارند. در اين پروژه‌ها برنامه‌نويسان ساعت‌هاي زيادي را صرف تهيه نرم‌افزاري مي كنند كه مملو از مشكل است و تلاش آنان چنان كه بايد، مؤثر نيست. وقتي با اين مشكلات مواجه مي‌شويم، به اين فكر مي‌افتيم كه بايد در كار خود روش و رويه‌اي درست داشته باشيم كه فعاليت‌هاي مربوط به پروژه در آن مشخص و منظم باشد، نيازهاي كاربران در آن مشخص باشد و خروجي نرم‌افزار و محصولات پروژه با موفقيت توليد شوند. براي اين كار مي‌توانيم به تجربيات كسب شده در پروژه‌هاي گذشته خود مراجعه كنيم و فعاليت‌هاي موفقي كه در آن پروژه‌ها انجام شده است را دوباره انجام دهيم و از كارهايي كه باعث مشكل در آن پروژه‌ها گشته‌اند، پرهيز كنيم. البته نمي‌توانيم با اين كار از وجود مشكل در نرم‌افزار خود مطمئن باشيم؛ زيرا مشكلات، چه بخواهيم چه نخواهيم، بروز خواهند كرد و از آن جايي كه در كار رويه‌اي ثابت نداريم و تنها از تجربيات قديمي خود استفاده مي‌كنيم، نمي‌توانيم انتظار داشته باشيم كه نرم‌افزارهاي ما بدون اشكال باشند؛ زيرا ممكن است با مشكلي برخورد كنيم كه تا به حال با آن برنخورده‌ايم و تجربه‌اي در رفع آن نداريم. اوايل سال 2001 تعدادي از محققان و صاحب‌نظران نرم‌افزار، گروهي به نام Agile Alliance را تشكيل دادند كه توانست راه‌حلي براي تيم‌هاي نرم‌افزاري پيدا كند تا به سرعت و با كيفيت بالا نرم افزار توليد كنند و بتوانند اگر تغييري در قسمتي از نرم‌افزار به وجود آمد، آن را كنترل كنند و اصلاحات لازم را اعمال نمايند. آن‌ها مدعي هستند كه راه بهتري براي توليد نرم‌افزار پيشنهاد كرده‌اند كه كار ما برنامه‌نويسان را آسان كرده است. آن‌ها چند اصل مهم را به عنوان مانيفيست يا بيانيه خود در نظر گرفته‌اند. از جمله: اهميت نقش اعضاي تيم در پروژه نرم‌افزاري، توليد مستندات مناسب براي نرم‌افزار، اهميت نقش كاربران سيستم و استفاده از آن‌ها در مراحل ساخت نرم‌افزار، و توانايي اعمال تغييرات در نرم‌افزار در تمامي مراحل توليدي آن. اهميت نقش اعضاي تيم در پروژه نرم‌افزاري يك رويه صحيح و مناسب در توليد نرم‌افزار به تنهايي نمي‌تواند از شكست پروژه جلوگيري نمايد، اگر از افراد مناسب در پروژه استفاده نشود. البته انتخاب رويه‌اي نامناسب نيز مي‌تواند باعث عدم كارايي اعضاي تيم شود؛ حتي اگر بسيار كاركشته هم باشند. به طوري كه حتي گروهي از بهترين برنامه‌نويسان نيز اگر در تيم منسجم كار نكنند، نمي‌توانند تمام كارايي خود را در اختيار پروژه قرار دهند. يك عضو مؤثر و قوي در تيم نيازي ندارد كه يك برنامه‌نويس سطح بالا و قوي باشد. او مي‌تواند يك برنامه‌نويس معمولي باشد، اما كسي باشد كه با ديگر اعضاي تيم به خوبي كار كند و با آنان رابطه خوبي داشته باشد. يك تيم با برنامه‌نويسان معمولي‌اي كه مي‌توانند به صورت منسجم كار كنند و با هم ارتباط خوبي داشته باشند، بهتر از گروهي از بهترين برنامه‌نويسان است كه نمي توانند كار تيمي انجام دهند و با موفقيت پروژه‌اي را به اتمام برسانند. البته نبايد نقش مهم ابزارهاي برنامه‌نويسي مناسب و ابزار CASE را در موفقيت پروژه‌هاي نرم‌افزاري ناديده گرفت. كامپايلرها، IDEها، سيستم‌هاي كنترلي سورس كدهاي برنامه و ... همگي مي‌توانند باعث شوند اعضاي تيم به خوبي و با دقت بيشتري كار خود را انجام دهند. البته استفاده زياد از ابزارهاي برنامه‌نويسي و كمكيِ مهندسان نرم‌افزار مي‌تواند اثر معكوس نيز داشته باشد. يكي از نكات قابل اهميت كه مديران پروژه‌ها بايد بدانند اين است كه اولين كاري كه بايد انجام دهند، ايجاد تيمي مناسب براي پروژه است؛ حتي قبل از اين‌كه محيط كاري مناسب را براي آن تيم فراهم آورند. ابتدا بايد تيمي كارا و همگام با هم تشكيل داد. سپس اجازه داده شود خود اعضاي آن تيم در مورد نيازهاي ابزاري و محيطي خود تصميم بگيرد. توليد مستندات نرم‌افزار بدون مستندات را مي‌توان مانند خانه‌اي تجسم كرد كه نقشه سيم‌كشي برق، لوله‌كشي و هيچ‌گونه نقشه ديگري ندارد. حال تجسم كنيد كه اگر قسمتي از برق اين ساختمان ايراد پيدا كند، چه كاري مي‌توانيم انجام دهيم؟ يا بايد از برقكاري كه آن ساختمان را قبلاً برق كشي كرده است درخواست كنيم كه به ما كمك كند (البته پيدا كردن او نيز كار آساني نيست و ممكن است هيچ‌وقت او را پيدا نكنيم). راه‌حل بعدي اين است كه ديوارهاي خانه را خراب كنيم تا سيم‌ها را پيدا كنيم و نقص سيم‌كشي را برطرف نماييم و به اين صورت در حقيقت يك فاجعه به تمام معني براي صاحبخانه پيش ميآيد. براي پيدا كردن اشكالي كوچك يا ارتقاي سيستم برقي چه مشكلاتي سر راه خواهند بود؛ اگر نقشه برق ساختمان موجود نباشد. حال تجسم كنيد نرم‌افزاري فاقد مستندات باشد و برنامه‌نويس آن نيز در دسترس نباشد. كدهاي برنامه نمي‌توانند به تنهايي و بدون راهنما و مستندات توسط ديگر افراد قابل فهم باشند. طراحان نرم‌افزار بايد مستنداتي فراهم كنند كه بتواند به كسي كه بعدها به آن كدها مراجعه مي‌كند نشان دهد كه طراحان اوليه اين سيستم چگونه ساختار برنامه را درست كرده‌اند. البته درست كردن مستنداتِ زياد و غيرضروري كار درستي نيست و وقت تلف كردن است. مهندسان نرم‌افزار اصطلاح خوبي براي مستندات دارند و مي‌گويند: مستندات نرم‌افزار بايد <كوتاه> و <ساكت> باشد. منظور از كوتاه اين است كه بايد مختصر و دقيق باشد و منظور از ساكت اين است كه نبايد خيلي به جزئيات غيرضروري بپردازد و خواننده را خسته نمايد. اهميت نقش كاربران سيستم در پروژه نرم‌افزار را نمي‌توان مانند اجناس ديگر سفارش داد. نمي‌توانيد انتظار داشته باشيد كه شرح فني نرم‌افزاري را بنويسيد و از كسي بخواهيد آن را در مدت زمان معين و با قيمت معين به اتمام برساند. پروژه‌هاي نرم‌افزاري كه اين‌گونه سفارش داده شده‌اند، اكثراً شكست خورده‌اند. پروژه‌هاي موفق پروژه‌هايي هستند كه در آن كاربران به صورت مستقيم در مراحل اجرايي پروژه دخيلند و نظرات مشتريان كه همان كاربران سيستم باشند، از ابتدا مورد توجه قرار گرفته است. اگر كاربران سيستم در تمامي مراحل توليد نرم‌افزار حضور داشته باشند و در مورد كار و محصول به دست آمده تا آن زمان اعلام نظر كنند، مي‌توان مطمئن بود پس از اتمام كار انتظار بالاتري از سيستم نخواهد داشت. توانايي اعمال تغييرات در نرم‌افزار و برنامه‌ريزي موقت به راستي مي‌توان عامل موفقيت يا عدم موفقيت يك پروژه نرم‌افزاري را در توانايي يا عدم توانايي آن در پاسخ به تغييرات دانست؟ برنامه اجرايي پروژه بايد انعطاف‌پذيري مناسبي داشته باشد و بتوان آن را متناسب با تغييرات احتمالي آينده تغيير داد. معمولاً مديران پروژه‌ها چارت و برنامه زمانبندي پروژه را روي ديوار نصب مي‌كنند. با اين كار مي‌توانند تكاليف هر شخص در تيم را كنترل نمايند و قسمت‌هاي انجام شده را با خط قرمز روي آن برنامه مشخص كنند. اما مشكلي كه در اين قسمت ممكن است پيش آيد اين است كه بعد از مدتي ساختار اين برنامه به هم خواهد خورد؛ چرا كه اولاً اعضاي تيم در مورد پروژه اطلاعات خوبي كسب كرده‌اند و برخي از تكاليف آنان غيرضروري خواهد شد. از طرف ديگر، مشتري و كاربران آينده سيستم نيز در جريان كار قرار مي‌گيرند و ممكن است نيازهاي خود را افزايش دهند و تكاليف بيشتري براي اعضاي تيم به ارمغان بياورند. با اين كار تمام برنامه زمانبندي پروژه به هم خواهد خورد. راه بهتري كه مي‌توان پيش گرفت اين است كه برنامه‌اي دقيق براي مثلاً دوهفته در نظر بگيريم، برنامه‌اي تقريبي براي دو يا سه ماه آينده مشخص كنيم و برنامه‌اي باز هم تقريبي‌تر براي بعد از آن. دليل منطقيِ اين‌گونه برنامه‌ريزي اين است كه با اين كار مي‌توانيم اگر مثلاً نيازهاي كاربر تغيير كرد، در مرحله بعدي برنامه خود آن تغيير را در نظر بگيريم. اصول توليد نرم‌افزار به روش Agile Development ●جلب رضايت كاربر سيستم با ارائه نرم‌افزارهاي با كيفيت ● نيازهاي كاربران ممكن است عوض شود؛ حتي در مراحل پاياني پروژه. در Agile Development گروه آمادگي قبول هرگونه تغييري را در هر مرحله از پروژه دارد. ● توليد سريع نرم‌افزار با تبديل آن به چند قطعه و ارايه آن به مشتري ● كاربران آينده سيستم و توليدكنندگان نرم‌افزار بايد از ابتداي پروژه با هم همكاري كنند. ● ايجاد محيط كاري مناسب براي اعضاي تيم در پروژه ● يكي از بهترين روش‌ها براي گرفتن اطلاعات و تبادل آن، ايجاد ارتباط گفتاري با ديگر اعضاي تيم در پروژه است. ● در پروژه‌هايي كه به روش Agile توليد مي‌شوند، معيار موفقيت پروژه و رويه انتخابي، ميزان رضايت مشتري از نرم‌افزار توليد شده و نيازهايي است كه برآورده شده‌اند. ● اعضاي تيم در اين روش در كار خود آهسته و پيوسته عمل مي‌كنند. ●اعضاي تيم در اين روش بايد بيشترين تلاش خود را براي نوشتن نرم‌افزارهايي با كيفيت بالا به عمل آورند. ●انتخاب بهترين و آسان‌ترين راه براي رسيدن به هدف اصلي پروژه در حقيقت هدف اصلي هر برنامه‌نويس و تمامي تيم‌هاي نرم‌افزاري، ارائه بهترين سرويس و محصولي با كيفيت بالا به مشتريان خود است. Agile Software Development راهي است براي رسيدن به اين منظور. چندين روش مانندScrum ،Adaptive Software Development و Extreme Programming) XP) مي‌توانند به شما كمك كنند. نرم‌افزارهايي با كيفيت بالا بسازيد و اطمينان حاصل كنيد كه پروژه نرم‌افزاري شما با موفقيت به پايان مي‌رسد. اگر مي‌خواهيد در مورد روش‌هاي ذكر شده اطلاعات بيشتري كسب نماييد مي‌توانيد، به مقاله‌اي با همين قلم با نام <مناسب‌ترين روش براي توليد نرم‌افزارهاي كوچك> در شماره 66 ماهنامه مراجعه كنيد. در يادداشت‌هاي بعدي سعي خواهم كرد روش‌هايي از اين نوع برنامه‌نويسي را به صورت عملي مورد بررسي قرار دهم.
مطالب مشابه :
مستندات نیازمندی ها و نقش آن در موفقیت یک پروژه نرم افزاری
برای انجام یک پروژه نرم افزاری معمولاً مشتری نیازهایش را در یک فرمت خاص (چه مکتوب و چه شفاهی
چگونه یک پروپوزال خوب برای نرم افزار بنویسیم؟
طرح مديريت پروژه نرم افزار ( spmp ) - استانداردهاي پروژه - مستندات طراحي و توسعه
مندرجات سند نيازهاي نرم افزار (SRD)
مندرجات طرح مديريت پروژه نرم افزار راهنماي كاربر نرم افزار در مجموعه مستندات پروژه.
معرفی نرم افزار PRIMAVERA EXPEDITION
نرم افزار محصول شرکت پریماورا می باشد که قابلیت کنترل پروژه از زمان عقد قرارداد تا پایان
Agile Software Development
مستندات نرم‌افزار بايد اهميت نقش كاربران سيستم در پروژه نرم‌افزار را نمي‌توان
تطبيق استانداردهاي موجود براي مستند سازي سيستم هاي اطلاعاتي در ايران
مستندات نرم‌افزار، به هر مطلبي اين سند هميشه قبل از آغاز يك پروژه نرم‌افزاري تهيه
طراحی نرم افزار
مدل تولید سریع نرم افزار. مدیریت پروژه دشوار مستندات نرم‌افزار
برچسب :
مستندات پروژه نرم افزار