انجمن برنامه نویسان البرز

تبلیغات

تفاوت های متدولوژی agile و روش های آبشاری در چیست؟

تفاوت های متدولوژی agile و روش های آبشاری در چیست؟


همانطور که  قبلا در مقاله Unit Testing توضیح دادیم، چیزی که اسکرام و به طور کلی متدولوژی Agile را از سایر روش های مدیریت پروژه ، متمایز میکند، استقبال آنها از تغییرات و توسعه افزایشی است. در متدولوژی Agile باور ما بر این است که امکان ندارد یک پروژه نرم افزاری با معلوماتی که در ابتدای کار داریم، از ۰ تا ۱۰۰ تولید شود.

در متدولوژی های قدیمی تر (متدولوژی های آبشاری) همیشه مراحل به صورت ترتیبی و پشت سر هم استفاده میشوند. دریافت نیازها،تحلیل و طراحی و …

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

اتفاقی که در متدولوژی های آبشاری، بسیار متداول است

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

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

مشتری نمیداند چه میخواهد و این کاملا طبیعی است!

واقعیت این است که یک مشتری، برنامه نویس نیست. با رویه های تولید نرم افزار آشنایی ندارد. پس خیلی طبیعی است که مشتری نداند دقیقا چه میخواهد. این ندانستن، جزء لاینفک یک پروژه نرم افزاری است. این ما هستیم که رویه های تولید نرم افزار را میشناسیم و باید به مشتری کمک کنیم تا بفهمد چه میخواهد. اما چطور؟ جواب این سوال همانقدر که ساده است، سخت هم هست: “باید به مشتری نشان بدهیم مرحله به مرحله کار را نشان بدهیم و از او بازخورد بگیریم.”  این جمله، شاید مهم ترین اصل متدولوژی agile باشد.

متدولوژی agile چیز کاملا جدیدی نیست

واقعیت این است که متدولوژی agile یک جادو نیست که از فضا رسیده باشد. agile در واقع، نوع خلاصه شده ای از یک متدولوژی آبشاری است. در واقع یک متدولوژی آبشاری که در تناوب های ۲ تا ۴ هفته ای، تکرار میشود. بیایید این قضیهرا بیشتر بررسی کنیم. همانطور که گفتیم، در متدولوژی آبشاری، نیازمندی ها را از مشتری میگیریم و تحلیل میکنیم و کد میزنیم و تست میکنیم و محصول را تحویل میدهیم. در agile همین کار را انجام میدهیم. البته با چند تفاوت کوچک. در agile پروسه تست را همزمان با تولید انجام میدهیم. یعنی هر چه را تولید میکنیم، بلافاصله تست میکنیم. حتی گاهی آنرا قبل از تولید تست میکنیم! به علاوه، در agile ما به جای اینکه تمام محصول را تولید کنیم، آنرا به قسمت های مجزا از هم میشکنیم و هر قسمت را جداگانه میسازیم و تست میکنیم و به مشتری تحویل میدهیم. همانطور که میبینید، متد آبشاری را در یک زمان ۲ تا ۴ هفته ای استفاده میکنیم.

 

 




کلمات کلیدی :

نظر بدهید