مشاهده خبر بازگشت به لیست اخبار

سومین اصل اجایل: زمان برای هیچ کسی صبر نمی کند!

نوشته شده توسط: فروزان
در تاریخ:

در توسعه اجایل، نیازمندی ها تکامل می یابند اما بازه های زمانی ثابت هستند.

این در تضاد کامل با یک پروژه توسعه سنتی است، جایی که یکی از اولین اهداف، شناختن تمام نیازمندی ها و دامنه آن ها است. به طور سنتی، کاربران یاد گرفته اند که در طول ساخت نرم افزار یا پس از آن، افزودن یا تغییر نیازمندی ها بسیار هزینه بر است. بعضی از سازمان ها برای ترساندن کاربران طرح های آماری موثر را نقل قول کردند. در نتیجه: فکر کردن به آنچه که می توانند فکر کنند- در واقع هر آنچه در رؤیایشان وجود دارد، تبدیل به امری ضروری می شود. و اینکه اولین انتشار بسیار مهم است، زیرا که همه ما می دانیم است زمانی که 80 درصد مزایا در فاز یک منتشر شده است، تصویب فاز 2 بسیار سخت است. از قضا، کاربران ممکن است تنها از بخش کوچکی از نرم افزار استفاده کنند، شاید 20 درصد یا حتی کمتر، با این حال بسیاری از پروژه ها با کمترین دامنه شروع به کار میکنند. به این دلیل است که هیچ کس در ابتدا مطمئن نیست که کاربران آنها درواقع از 20 درصد محصول هم استفاده کنند. به همان اندازه حتی اگر نیازمندی ها به دقت تجزیه تحلیل و اولویت بندی شوند، فکر کردن به همه چیز غیر ممکن است، همه چیز تغییر می کند و همه چیز توسط افراد متفاوت، متفاوت درک می شود.

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

بنابراین اگر این نکته را باور دارید - زمانی که نیازمندی ها نوشته شده اند هیچ کسی واقعا نمی تواند راجع به راه حل مناسب مطمئن شود - ذاتا دشوار است و حتی عملا غیر ممکن است که با استفاده از یک رویکرد سنتی توسعه نرم افزار، راه حل مناسب را بسازیم.

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

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

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

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

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


منبع: Agile Principle 3: Time Waits For No Man!
برچسب ها: -

هیچ دیدگاهی تاکنون برای این خبر ثبت نشده است.

اولین نفر باشید!
دیدگاه خود را ثبت کنید: